7 ms·

This looks very helpful. I've had some trouble migrating from a GUI Subversion client to command-line Git.

maurycy 17y ago
Everyone I know seems to have. :-) Personally, I'm a bit disgusted with the git hype. I love the git idea but the interface is horrible.
- pyre 17y ago
  There are some nice-looking Git clients, but most of them seem to be for OS X. I haven't used them though as I don't have a Mac and I prefer the command-line client. Part of the problem is that there is not 'git library' last I checked. Git started out as a loosely strung-together set of commands that vary from compiled C-code to Perl scripts to plain shell scripts. Over time the bottlenecks have been ironed out and ported to C and such, but git is under heavy development even now. Just follow the git mailing list for a while to see. Also do some searching for stuff about JGit which is a git implementation in Java. Last I heard they were having a lot of trouble getting the performance to match the actual git tools because most of the bottlenecks had been fixed in the 'official' tools using highly optimized C-code. {edit} I guess I should add that the JGit stuff is information I read somewhere, but I don't recall if it was in a blog post/comment/mailing list email/etc.
  - maurycy 17y ago
    I'm used to the command line interfaces. It is not that I need a GUI tool. I do not. It's just that, after a year, I'm still not 100% sure that I understand what every git command does. There's still something under the hoods going on that I do not trust. I do not want to use a GUI interface, which I trust even less. Of course, you can either ask specific questions what causes me problems and answer them, or just reply me that powerful tool has a steep learning curve. I reject this notion, though. Perforce, Darcs and Bazaar are similarly powerful tools, with their own trade-offs. None gave me so much headache initially, and relatively quickly I've got some level of comfort with them. As for lack of "git library", I think you nailed it, if it's still true. +1. Lack of proper encapsulation is one of the biggest issues in the Linux tools' world. Most of the tools is "as is", and the only way to interact with them is the command line. I know that this is a part of the Unix philosophy. It frequently, though, generates similar problems. The idea is excellent, yet the interface is horrible. It shouldn't be the case. Why give up excellent, already written, code and idea, because of something so trivial as interface? It's especially visible in the world of package management software. Nearly all come as a package: their own format, their own repos, their own scripts, and the command-line interface. I still don't understand why there's neither single packages' format, nor scripts cannot be reused, and everyone reinvents the wheel on daily basis. By the way, thanks for not downvoting me. I expected a different outcome.
    - pyre 17y ago
      > It's especially visible in the world of package management software. Nearly all come as a package: their own format, their own repos, their own scripts, and the command-line interface. I still don't understand why there's neither single packages' format, nor scripts cannot be reused, and everyone reinvents the wheel on daily basis. People aren't 'reinventing' the wheel constantly. There are only two major package management structures (deb/rpm) and there are even tools to translate between them, IIRC. Why 'their own repos?' Because if they make design decisions that are incompatible with the current repository, they have to host their own. It's not like Ubuntu and Debian are mutually exclusive as far as repositories go. Ubuntu pulls over a 'snapshot' of Debian's unstable repository, applying patches where they need to and/or see fit. There are probably plenty of packages in Ubuntu that are unchanged from what they were in the Debian Unstable repository. I'm sure it's the same with Ubuntu-based distros like Mint. They probably pull over a snapshot of the Ubuntu repos, make their modifications and it becomes their next revision of Mint. > Bazaar Bzr has its own set of headaches. I haven't used it extensively, but IIRC they use revision numbers on commits that are only valid locally, which I think is a big no-no. Especially with people coming from other version control systems that use the revision number as the canonical pointer to a specific revision.
- davepeck 17y ago
  By interface, I assume you mean git's command-line interface? I agree; it's terrible. My impression is that projects like grit are far enough along that it should be possible to build an entirely new git front-end/porcelain on a clean technology stack. Something with more sane exposure. I don't know if anybody's actually working on something like this right now?
  - mbrubeck 17y ago
    David Roundy (author of Darcs, a DVCS that predates git and has one of the nicest command-line interfaces) is working on a git porcelain that has the same user interface and semantics as Darcs: http://github.com/droundy/iolaus http://github.com/droundy/iolaus
    - davepeck 17y ago
      Thanks for the pointer -- I played with Darcs back in the day. This looks interesting.
  - markkoberlein 17y ago
    I actually like the command-line interface and prefer it over the GUI interfaces. However, I do prefer the command line for almost everything from managing databases to editing source files in VIM. Git's command-line is a natural fit for that kind of workflow.
    - dasil003 17y ago
      I prefer the command line as well for version control (regardless of flavor), but git's porcelain is pretty horrendous. I think the worst offender is git-checkout, which can switch branches, detach from a branch entirely, or just update the working copy of a file with a different revision. However despite the power and complexity of git's interface I find I better understand and feel more comfortable with git after one year of daily use than I ever was with subversion and cvs even after a decade.
- kajecounterhack 17y ago
  what about gitk (*nix) / gitx (mac) ? granted it's not really a gui so much as a visualization...
- doki_pen 17y ago
  It's not that bad. I never enjoyed using Tortoise and always stuck with cli svn. git's tools set is far superior to svn's.

Everyone I know seems to have. :-) Personally, I'm a bit disgusted with the git hype. I love the git idea but the interface is horrible.

pyre 17y ago
There are some nice-looking Git clients, but most of them seem to be for OS X. I haven't used them though as I don't have a Mac and I prefer the command-line client. Part of the problem is that there is not 'git library' last I checked. Git started out as a loosely strung-together set of commands that vary from compiled C-code to Perl scripts to plain shell scripts. Over time the bottlenecks have been ironed out and ported to C and such, but git is under heavy development even now. Just follow the git mailing list for a while to see. Also do some searching for stuff about JGit which is a git implementation in Java. Last I heard they were having a lot of trouble getting the performance to match the actual git tools because most of the bottlenecks had been fixed in the 'official' tools using highly optimized C-code. {edit} I guess I should add that the JGit stuff is information I read somewhere, but I don't recall if it was in a blog post/comment/mailing list email/etc.
- maurycy 17y ago
  I'm used to the command line interfaces. It is not that I need a GUI tool. I do not. It's just that, after a year, I'm still not 100% sure that I understand what every git command does. There's still something under the hoods going on that I do not trust. I do not want to use a GUI interface, which I trust even less. Of course, you can either ask specific questions what causes me problems and answer them, or just reply me that powerful tool has a steep learning curve. I reject this notion, though. Perforce, Darcs and Bazaar are similarly powerful tools, with their own trade-offs. None gave me so much headache initially, and relatively quickly I've got some level of comfort with them. As for lack of "git library", I think you nailed it, if it's still true. +1. Lack of proper encapsulation is one of the biggest issues in the Linux tools' world. Most of the tools is "as is", and the only way to interact with them is the command line. I know that this is a part of the Unix philosophy. It frequently, though, generates similar problems. The idea is excellent, yet the interface is horrible. It shouldn't be the case. Why give up excellent, already written, code and idea, because of something so trivial as interface? It's especially visible in the world of package management software. Nearly all come as a package: their own format, their own repos, their own scripts, and the command-line interface. I still don't understand why there's neither single packages' format, nor scripts cannot be reused, and everyone reinvents the wheel on daily basis. By the way, thanks for not downvoting me. I expected a different outcome.
  - pyre 17y ago
    > It's especially visible in the world of package management software. Nearly all come as a package: their own format, their own repos, their own scripts, and the command-line interface. I still don't understand why there's neither single packages' format, nor scripts cannot be reused, and everyone reinvents the wheel on daily basis. People aren't 'reinventing' the wheel constantly. There are only two major package management structures (deb/rpm) and there are even tools to translate between them, IIRC. Why 'their own repos?' Because if they make design decisions that are incompatible with the current repository, they have to host their own. It's not like Ubuntu and Debian are mutually exclusive as far as repositories go. Ubuntu pulls over a 'snapshot' of Debian's unstable repository, applying patches where they need to and/or see fit. There are probably plenty of packages in Ubuntu that are unchanged from what they were in the Debian Unstable repository. I'm sure it's the same with Ubuntu-based distros like Mint. They probably pull over a snapshot of the Ubuntu repos, make their modifications and it becomes their next revision of Mint. > Bazaar Bzr has its own set of headaches. I haven't used it extensively, but IIRC they use revision numbers on commits that are only valid locally, which I think is a big no-no. Especially with people coming from other version control systems that use the revision number as the canonical pointer to a specific revision.
davepeck 17y ago
By interface, I assume you mean git's command-line interface? I agree; it's terrible. My impression is that projects like grit are far enough along that it should be possible to build an entirely new git front-end/porcelain on a clean technology stack. Something with more sane exposure. I don't know if anybody's actually working on something like this right now?
- mbrubeck 17y ago
  David Roundy (author of Darcs, a DVCS that predates git and has one of the nicest command-line interfaces) is working on a git porcelain that has the same user interface and semantics as Darcs: http://github.com/droundy/iolaus http://github.com/droundy/iolaus
  - davepeck 17y ago
    Thanks for the pointer -- I played with Darcs back in the day. This looks interesting.
- markkoberlein 17y ago
  I actually like the command-line interface and prefer it over the GUI interfaces. However, I do prefer the command line for almost everything from managing databases to editing source files in VIM. Git's command-line is a natural fit for that kind of workflow.
  - dasil003 17y ago
    I prefer the command line as well for version control (regardless of flavor), but git's porcelain is pretty horrendous. I think the worst offender is git-checkout, which can switch branches, detach from a branch entirely, or just update the working copy of a file with a different revision. However despite the power and complexity of git's interface I find I better understand and feel more comfortable with git after one year of daily use than I ever was with subversion and cvs even after a decade.
kajecounterhack 17y ago
what about gitk (*nix) / gitx (mac) ? granted it's not really a gui so much as a visualization...
doki_pen 17y ago
It's not that bad. I never enjoyed using Tortoise and always stuck with cli svn. git's tools set is far superior to svn's.