6 ms·

Git needs a new interface

32 points by r11t 17y ago

superjared 17y ago
No it doesn't.
- johnbender 17y ago
  I fully agree with the above poster and his sentiment.
- davidw 17y ago
  Why don't you try refuting some of his points? Or else he might come back with "does too!"... I'm not overly impressed with git in terms of it doing the right thing by default. The best options are often sort of hidden away under some option that you have to remember. svn is much simpler and nicer from this point of view in that I don't often have to use flags with it to do the basics. Perhaps the title could be rephrased as something like: "if git hopes to grow outside the world of early adopters, it probably needs a better interface", although that's not nearly as snappy... While we're at it... can anyone: * Comment on mercurial and bzr from this point of view? * Comment on TortoiseGit?
  - jjames 17y ago
    * "checkout" is a destructive command Most VCSs have a destructive command. If one doesn't expect the destruction from the command, they will no doubt be perturbed. * You can’t merge upstream changes into your local, uncommitted modifications Commit. * Git’s merge conflict resolution workflow is unintuitive Subjective but I'm curious which VCS has an intuitive merge conflict resolution workflow. I assume this means that without previous experience with the VCS a developer can (immediately?) intuit the workflow. * Interface for working with the index almost universally confusing Three switches for a single command. If you want to operate in a business as usual DWIM manner you can just remember --hard. All that said, I do believe git reuses some commands in a semantically elastic way, sometimes to the confusion of new users.
    - davidw 17y ago
      > Most VCSs have a destructive command. And the name tips you off that you're about to do something destructive. Like svn's "revert". On the other hand, 'checkout' sounds fairly innocent to me. > intuitive merge conflict resolution workflow. IIRC, recent versions of svn walk you through it, asking which one you want to keep or letting you edit the file(s). I actually use git (the branches are really nice for some things), but I'm considering VC systems for office use, and I'm not quite so sure I'd stick my neck out and recommend git.
      - masklinn 17y ago
        > I actually use git (the branches are really nice for some things) FWIW Mercurial now has git-style branches (called bookmarks, hg's branches are different beasts)
  - stonemetal 17y ago
    To me it reads like a why use mercurial instead of git piece.
    - itistoday 17y ago
      Same here, 'cept s/mercurial/bazaar/g. ;-)
      - dlsspy 17y ago
        bzr's UI confuses the hell out of me. I have friends who know it really well and I usually ask them how to do things that are simple in git. In some cases I just hear that they would rather not do that [thing that is important to me]. As far as I can tell, it's because the tool doesn't allow them to. It's all a matter of perspective.
        davidw 17y ago
        What sorts of things, out of curiosity?
        dlsspy 17y ago
        I had a small change sitting in a branch for about a month and wanted to update. I didn't want to do a merge. I did find that someone had created a simple rebase plugin for bzr, though. That made things a lot easier. I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code. Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project. That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did. Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge. I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project. Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer. Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].." I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.
MarkPNeyer 17y ago
github.com is great for use with git. Disclaimer: I went to high school with (and am an arch rival of) the founder.
- m0th87 17y ago
  How does it improve on git's interface, besides providing a UI for browsing the trunk and visualizing merges? I've just started using github, and while I see the value of git (especially in its branch-oriented philosophy), I always have to look up how to do even the basics. While I understand git is far more powerful, I like svn because it 'just works'.
  - deleted 17y ago
    [deleted]
  - deleted 17y ago
    [deleted]
  - gecko 17y ago
    You might give Mercurial a shot. It's the speed of Git with a much saner user experience. Plus, all the power of Git's there; it's just hidden under the covers until you need it. Speaking of the examples in this article: hg update allows you to fast-forward without making a commit. The equivalent of git checkout in Mercurial is (roughly) hg update -c which will refuse to update if you have changes. (You can override that with "hg update -C".) In the case of merge output, when you've fixed a file, you simply run hg resolve filename You can at any point see what's not merged by running hg resolve --list Notably, if you have a three-way merge tool set up properly, you'll never do this, because Mercurial will walk you through doing the merge properly as part of the...well, merge.
    - stevejohnson 17y ago
      "It's the speed of Git..." No it's not. Speaking from experience here. Edit: Okay, here's some real data: http://git.or.cz/gitwiki/GitBenchmarks http://git.or.cz/gitwiki/GitBenchmarks http://whygitisbetterthanx.com/#git-is-fast http://whygitisbetterthanx.com/#git-is-fast It shows that git wins by most metrics, with a few exceptions. Mercurial's push/pull format is particularly good.
stevejohnson 17y ago
While I agree that git's error messages can be unhelpful, I still think that this guy is using git improperly when he tries to "merge upstream changes into your local, uncommitted modifications." A huge motivation for using a DVCS is that you can commit as many times as you want without worrying that your in-progress, hacky changes will affect someone else's work. Combined with git's powerful branching, you should never have an excuse not to commit a change set before a merge. Also, he whines about not being able to merge with uncommitted changes, and then gives an example of how to do it! Ridiculous. It's three intuitive commands. That's what stashing is for. I do agree with his points about git reset. The args are very confusing. Reverting to the most recent commit should be more intuitive. However, these arguments do not in any way point toward a need for an entirely new interface.
- moe 17y ago
  However, these arguments do not in any way point toward a need for an entirely new interface. No, but the sum of the arguments does. I'd wager that most git users feel that the UI is more complex than it should be and outright hostile in many situations. The problem is that not many people are deep enough into all the concepts to make a coherent proposal for something better. And those who could often don't see the problems anymore because it's just the way it is for them (can we coin the term VCS-blindness right here?). It's sort of a chicken/egg problem and hard one. I, for example, am not exactly happy that my standard procedure for pushing changes upstream has to involve 7 commands and two rebases. But so far I've had neither the time nor the insight or motivation to come up with something better. My general feeling is that git is still exposing itself at too low a level. That's also the reason why so many people are using it "wrong" (wanna make a bet on how many projects on github consist of only a master-branch where everything happens?). Consequently my best stab would be that git could perhaps use a bit syntactic sugar for the most common workflows. There are not so many of them after all - why does almost everybody have to repeat the same 7 commands every day?
mjgoins 17y ago
The title is a wild exaggeration. The article itself points out many UI gripes that every user of git runs into. Fixing those gripes would absolutely not constitute the creation of a new UI.
kinghajj 17y ago
1. "checkout" is a destructive command Yeah, so? "checkout <branch>" changes the working dir's files to match those of <branch>, and "checkout <file>" reverts <file>'s contents to its original. It's documented and does what it says. 2. You can’t merge upstream changes into your local, uncommitted modifications Why not just commit your "hacky" modifications onto a local branch? The great thing about Git is that your commits/checkins don't have to be perfect, since no-one else can see them until pushed/pulled/merged anyways. 3. Git’s merge conflict resolution workflow is unintuitive If you've used Git at all, you should be comfortable with the fact that you need to "git add" files before you "git commit" them. Resolving changes is no different. "git add" each conflicting file and then "git commit". 4. Interface for working with the index almost universally confusing Maybe you have a point there. I'm actually using Git GUI a lot more than the command-line now. The only time I've used the command-line recently is for pruning, which the GUI has no way to do (it can only compress). Git GUI is pretty friendly.
- mr_dbr 17y ago
  The git checkout [filename] behaviour always confused me.. Yes, it's documented, but git seems to really try and make it difficult to lose any work.. but has a command that makes it simple to irreversibly lose your upstaged changes, without so much as a warning? At least "git revert" sounds like it might undo changes.. In what way does "checkout" imply both "checking out" branches, and reseting a file to it's previously commited state?
davepeck 17y ago
I often refer to Git as "software of cruelty." I use it daily and sometimes still end up shocked by its behavior. The concepts underlying git -- a content-addressible filesystem, trees, commits, etc -- are elegant. They're nearly pure. The "front end" exposure on the command line? Not so much.
- aaronblohowiak 17y ago
  You can write your own porcelain, if you please. It seems a lot of people would like it, actually.
  - davepeck 17y ago
    Yes, it might be a good project. Are you aware of any other porcelains that have traction these days?
    - aaronblohowiak 17y ago
      sadly, no
steveklabnik 17y ago
> …will overwrite any local modifications you may have to foo.c without asking. *NIX commands do things without asking. Your computer serves you, not the other way around. If I wanted my computer to double check everything that I do, I'd run Windows. "(y/n/a)" just leads to awkward shell scripts.
- mhansen 17y ago
  Put a '-f' in your shell script, to force the overwrite
  - steveklabnik 17y ago
    Why don't you put a '--double-check-my-command' on yours?
    - mey 17y ago
      There is such a thing are reasonable defaults. This is an issue of command lines as interfaces and as tool integration points. You have reasonable defaults for both audiences. (My preference is the err on the side of the human interaction because CPU's are cheap)
      - jwhite 17y ago
        Git is unashamedly a power tool, for power users. Git checkout seems so natural to me in the way it functions, and I use it so often, that it would annoy the hell out of me if I had to force it or answer a y/n prompt every time I used it. What you think of as intuitive is not universal. Your reasonable defaults are unreasonable to me. This seems to be a problem of audience. Git can be challenging to learn, but it's not aimed at learners. It's aimed at power users. As others have pointed out, there are other front-ends to git. You don't have to use the default porcelain.
        mey 17y ago
        Fair enough
ErrantX 17y ago
Without wanting to add fuel to the fire (really), I always think Git tries to do far too much. I think SCM should just gracefully version your code in as simple a way as possible. I went from SVN to Git a while ago and it was a great improvement. Then a friend pointed me at mercurial and I just felt it was a revolution. Finally my code felt portable. With all that said Git has some great tools for large and complex projects with many contributors. The one thing that sells HG to me though is it's insistence on non-destructiveness. If you made changes to files it always reminds me to merge changes properly without overwrites. I cant recall how many times that has saved me a n hours work :)
- masklinn 17y ago
  FWIW, if you want simple (as far as concept & interface go anyway) check out darcs. It probably has the simplest, sanest and sexiest (CL) interface of all modern DVCS (Git, Mercurial, Bazaar, Darcs, …). Plus because of the concepts behind it, cherrypicking is Simply Trivial. Of course, the downside is that those concepts generate other issues.
  - ErrantX 17y ago
    thanks, I'll look into that.
senthilnayagam 17y ago
git porcelain is not ready for newbies, use tortoisegit or other gui interfaces. I dont understand why people should have uncommitted changes for days Branching is cheap and local, commits are local, no need to expose private work until it is ready to be merged with master, team accessible branches.
dlsspy 17y ago
> You can’t merge upstream changes into your local, uncommitted modifications No, you can't, and I'd be horrified if I ever worked in a system that did that again. First, there's never an excuse to not commit. What you commit is not necessarily what you publish. rebase -i to clean up artifacts of the junk you've done if you're worried about it (I always do it that way). But more importantly, when I pull code and what ends up is worse than what I had before, I'd like to go back to where I was.
- Oxryly 17y ago
  Agreed. I avoid merging (potentially extensive) outside changes/commits into my modified local files. It always seemed like a risky and unwise procedure in CVS and Perforce. I think Git's alternative of stash, pull, pop is an improvement. That way I can fix conflicts properly at each stage, and handle big changes before reapplying my hacked up stuff.
etherael 17y ago
> You can’t merge upstream changes into your local, uncommitted modifications If you're just hacking around, shouldn't the procedure be to have a branch specifically for that and keep master clean for urgent work? Confused.
- jwhite 17y ago
  Agreed. Local topic branch for experimental hacks. Rebase it when you want to integrate upstream changes.
  - moe 17y ago
    I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. Hacking just happens. We try this and that, something works and gets committed, something else doesn't and gets reverted. My working copy is littered with uncommited files nearly constantly, simply because I work and play on many things in parallel and committing every time I save a file would be a noticable overhead, just as merging between topic branches all day. I'm not complaining, we get along, my working copy and I, but I agree in some situations git could be more helpful than "xxx needs update" - and that's really just one symptom of many. I've been playing with mercurial a bit recently (yes, heresy) and can see why the git guys despise it, it's just not as pure. The main thing that stuck with me though, is that even though it's roughly comparable to git in terms of features, it is mindboggingly much more intuitive to use. Git could take a lesson from that and would not even have to give up much of the purity. Yes, "everything" should still be possible - but they damn sure could make the beaten paths a bit less spikey.
    - dlsspy 17y ago
      > I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. I don't either. I pretty much always work on master. If I find myself down a deep path that should've been a topic branch, I make one then and reset my master back to origin. > I've been playing with mercurial a bit recently (yes, heresy) and can see why the git guys despise it, it's just not as pure. The main thing that stuck with me though, is that even though it's roughly comparable to git in terms of features I used hg heavily for a long time before ever touching git. I did a bit of work on an older project that used hg recently and found myself unable to figure out how to do something I often easily do in git. I don't remember the exact details, but I ended up committing and tagging after doing a "trivial" change that ended up being wrong (I noticed before pushing). Rather than pollute my public history with garbage, I just wanted to undo the mess and go back and fix the brokenness and retag. When I used hg heavily, I was very well-versed with the ins and outs of mercurial queues for doing simple fixups like this. Not having used it recently, I had to go to the manual because I couldn't remember which combination of q-commands would do a simple effective rebase. I was especially sensitive here because the last time I was a heavy hg user, I did lose changes to queues because hg doesn't have anything like the wonderful safety net of reflog to allow me to just put my tree back in a prior stat and let me try a complicated merge/rebase again.
jrockway 17y ago
This article had a lot of potential, but misses the key points. What this article should say is: 1. Git needs a shared-library interface, so that interfaces to git can be built without quoting and parsing (the two most error-prone operations in computing). 2. Git's default scripts are a mix of shell, perl, and C that all parse command-line options in their own unique way. Eventually you find what works, but it's by random experimentation rather than by noticing patterns. 3. Git's default scripts are bloated. Quick, how many different ways are there to rebase ("git rebase", "git pull --rebase", ...) or fetch ("git fetch", "git remote update", ...)? Since the code is not necessarily shared, these operations may not even be exactly the same... just mostly the same. Basically, git is the best version control system available -- but that doesn't mean it's not a software engineering nightmare. It is. ("So why don't you fix this?", you ask? Easy: git works so well that this theoretical annoyance is very low on my list of things to fix. In a perfect world, all software would be beautiful snowflakes. In the real world, there's always something that needs even more fixing.)
- dlsspy 17y ago
  > 1. Git needs a shared-library interface, so that interfaces to git can be built without quoting and parsing (the two most error-prone operations in computing). Every special tool I've ever wanted to create in git I've been able to do with pipes in either shell scripts or python scripts using data export options generally used by the porcelain. People have built good APIs on top of this, and in a few cases built direct object access interfaces, but I stopped thinking library access was important when I started actually writing tools.
technomancy 17y ago
I use git every day via Magit (http://zagadka.vm.bytemark.co.uk/magit/ http://zagadka.vm.bytemark.co.uk/magit/), which is a joy to use. But every time I have to fall back to the shell for something nontrivial it just feels so awkward.

32 points by r11t 17y ago

superjared 17y ago

No it doesn't.

johnbender 17y ago
I fully agree with the above poster and his sentiment.
davidw 17y ago
Why don't you try refuting some of his points? Or else he might come back with "does too!"... I'm not overly impressed with git in terms of it doing the right thing by default. The best options are often sort of hidden away under some option that you have to remember. svn is much simpler and nicer from this point of view in that I don't often have to use flags with it to do the basics. Perhaps the title could be rephrased as something like: "if git hopes to grow outside the world of early adopters, it probably needs a better interface", although that's not nearly as snappy... While we're at it... can anyone: * Comment on mercurial and bzr from this point of view? * Comment on TortoiseGit?
- jjames 17y ago
  * "checkout" is a destructive command Most VCSs have a destructive command. If one doesn't expect the destruction from the command, they will no doubt be perturbed. * You can’t merge upstream changes into your local, uncommitted modifications Commit. * Git’s merge conflict resolution workflow is unintuitive Subjective but I'm curious which VCS has an intuitive merge conflict resolution workflow. I assume this means that without previous experience with the VCS a developer can (immediately?) intuit the workflow. * Interface for working with the index almost universally confusing Three switches for a single command. If you want to operate in a business as usual DWIM manner you can just remember --hard. All that said, I do believe git reuses some commands in a semantically elastic way, sometimes to the confusion of new users.
  - davidw 17y ago
    > Most VCSs have a destructive command. And the name tips you off that you're about to do something destructive. Like svn's "revert". On the other hand, 'checkout' sounds fairly innocent to me. > intuitive merge conflict resolution workflow. IIRC, recent versions of svn walk you through it, asking which one you want to keep or letting you edit the file(s). I actually use git (the branches are really nice for some things), but I'm considering VC systems for office use, and I'm not quite so sure I'd stick my neck out and recommend git.
    - masklinn 17y ago
      > I actually use git (the branches are really nice for some things) FWIW Mercurial now has git-style branches (called bookmarks, hg's branches are different beasts)
- stonemetal 17y ago
  To me it reads like a why use mercurial instead of git piece.
  - itistoday 17y ago
    Same here, 'cept s/mercurial/bazaar/g. ;-)
    - dlsspy 17y ago
      bzr's UI confuses the hell out of me. I have friends who know it really well and I usually ask them how to do things that are simple in git. In some cases I just hear that they would rather not do that [thing that is important to me]. As far as I can tell, it's because the tool doesn't allow them to. It's all a matter of perspective.
      - davidw 17y ago
        What sorts of things, out of curiosity?
        dlsspy 17y ago
        I had a small change sitting in a branch for about a month and wanted to update. I didn't want to do a merge. I did find that someone had created a simple rebase plugin for bzr, though. That made things a lot easier. I tend to commit lots of incremental progress. I talked to a couple of bzr users who do the same. They insisted that it was important to their project to include these changes that definitely don't compile (e.g. "committing because I'm getting up to go to the bathroom"), etc... in the long-term history of the project because it can help them remember what they were thinking when they were writing the code. Personally, I do the similar, but I rebase -i before I push and squash and reorder most of that down into small, working chunks that most accurately reflect the real changes to the project. That is, it's a higher priority to me to say what happened than how it happened. I'm thoroughly uninterested in what the state of the codebase was when you came up with the idea to work on something, how many times you pulled upstream code down, how many times you went to the bathroom, etc... I just want to know when your change went in that affected the state of the project, and exactly what it did. Theoretically, a recursive merge message would tell me this. In practice, it does not, and the merge diffs don't necessarily show the change that affected the tree, but the delta that had to be applied to resolve conflicts on the merge. I used to be a gnu arch user, and as such, I used to find it of utmost important to record every minor file save in my permanent history. I've learned since then that it doesn't help me actually understand the project. Also, the use of sequence numbers (hg has the same problem) causes a lot of confusion. Humans seem to like the idea that there's an easy to understand sequence, but that's false on any project with more than one developer. Specifically I had this problem with "buildbot try" -- the default implementation does a working-tree diff against the same revno upstream (e.g. if "bzr version-info" says 571, then it uses "bzr diff" to create a patch and sends it upstream against 571). However, if I've committed locally (because...that's just the right thing to do), then it will find either than upstream doesn't have a 572, or it's a different 572. Enter "bzr revision-info -rsubmit:" which introduces network (took 7.49 seconds for me just now) and "bzr diff -rrevid:[long-string-i-can't-double-click].." I can't tell you all of the exact scenarios that were causing me confusion, but they came down to things like the above.

MarkPNeyer 17y ago

github.com is great for use with git. Disclaimer: I went to high school with (and am an arch rival of) the founder.

m0th87 17y ago
How does it improve on git's interface, besides providing a UI for browsing the trunk and visualizing merges? I've just started using github, and while I see the value of git (especially in its branch-oriented philosophy), I always have to look up how to do even the basics. While I understand git is far more powerful, I like svn because it 'just works'.
- deleted 17y ago
  [deleted]
- deleted 17y ago
  [deleted]
- gecko 17y ago
  You might give Mercurial a shot. It's the speed of Git with a much saner user experience. Plus, all the power of Git's there; it's just hidden under the covers until you need it. Speaking of the examples in this article: hg update allows you to fast-forward without making a commit. The equivalent of git checkout in Mercurial is (roughly) hg update -c which will refuse to update if you have changes. (You can override that with "hg update -C".) In the case of merge output, when you've fixed a file, you simply run hg resolve filename You can at any point see what's not merged by running hg resolve --list Notably, if you have a three-way merge tool set up properly, you'll never do this, because Mercurial will walk you through doing the merge properly as part of the...well, merge.
  - stevejohnson 17y ago
    "It's the speed of Git..." No it's not. Speaking from experience here. Edit: Okay, here's some real data: http://git.or.cz/gitwiki/GitBenchmarks http://git.or.cz/gitwiki/GitBenchmarks http://whygitisbetterthanx.com/#git-is-fast http://whygitisbetterthanx.com/#git-is-fast It shows that git wins by most metrics, with a few exceptions. Mercurial's push/pull format is particularly good.

stevejohnson 17y ago

While I agree that git's error messages can be unhelpful, I still think that this guy is using git improperly when he tries to "merge upstream changes into your local, uncommitted modifications." A huge motivation for using a DVCS is that you can commit as many times as you want without worrying that your in-progress, hacky changes will affect someone else's work. Combined with git's powerful branching, you should never have an excuse not to commit a change set before a merge. Also, he whines about not being able to merge with uncommitted changes, and then gives an example of how to do it! Ridiculous. It's three intuitive commands. That's what stashing is for. I do agree with his points about git reset. The args are very confusing. Reverting to the most recent commit should be more intuitive. However, these arguments do not in any way point toward a need for an entirely new interface.

moe 17y ago
However, these arguments do not in any way point toward a need for an entirely new interface. No, but the sum of the arguments does. I'd wager that most git users feel that the UI is more complex than it should be and outright hostile in many situations. The problem is that not many people are deep enough into all the concepts to make a coherent proposal for something better. And those who could often don't see the problems anymore because it's just the way it is for them (can we coin the term VCS-blindness right here?). It's sort of a chicken/egg problem and hard one. I, for example, am not exactly happy that my standard procedure for pushing changes upstream has to involve 7 commands and two rebases. But so far I've had neither the time nor the insight or motivation to come up with something better. My general feeling is that git is still exposing itself at too low a level. That's also the reason why so many people are using it "wrong" (wanna make a bet on how many projects on github consist of only a master-branch where everything happens?). Consequently my best stab would be that git could perhaps use a bit syntactic sugar for the most common workflows. There are not so many of them after all - why does almost everybody have to repeat the same 7 commands every day?

mjgoins 17y ago

The title is a wild exaggeration. The article itself points out many UI gripes that every user of git runs into. Fixing those gripes would absolutely not constitute the creation of a new UI.

kinghajj 17y ago

1. "checkout" is a destructive command Yeah, so? "checkout <branch>" changes the working dir's files to match those of <branch>, and "checkout <file>" reverts <file>'s contents to its original. It's documented and does what it says. 2. You can’t merge upstream changes into your local, uncommitted modifications Why not just commit your "hacky" modifications onto a local branch? The great thing about Git is that your commits/checkins don't have to be perfect, since no-one else can see them until pushed/pulled/merged anyways. 3. Git’s merge conflict resolution workflow is unintuitive If you've used Git at all, you should be comfortable with the fact that you need to "git add" files before you "git commit" them. Resolving changes is no different. "git add" each conflicting file and then "git commit". 4. Interface for working with the index almost universally confusing Maybe you have a point there. I'm actually using Git GUI a lot more than the command-line now. The only time I've used the command-line recently is for pruning, which the GUI has no way to do (it can only compress). Git GUI is pretty friendly.

mr_dbr 17y ago
The git checkout [filename] behaviour always confused me.. Yes, it's documented, but git seems to really try and make it difficult to lose any work.. but has a command that makes it simple to irreversibly lose your upstaged changes, without so much as a warning? At least "git revert" sounds like it might undo changes.. In what way does "checkout" imply both "checking out" branches, and reseting a file to it's previously commited state?

davepeck 17y ago

I often refer to Git as "software of cruelty." I use it daily and sometimes still end up shocked by its behavior. The concepts underlying git -- a content-addressible filesystem, trees, commits, etc -- are elegant. They're nearly pure. The "front end" exposure on the command line? Not so much.

aaronblohowiak 17y ago
You can write your own porcelain, if you please. It seems a lot of people would like it, actually.
- davepeck 17y ago
  Yes, it might be a good project. Are you aware of any other porcelains that have traction these days?
  - aaronblohowiak 17y ago
    sadly, no

steveklabnik 17y ago

> …will overwrite any local modifications you may have to foo.c without asking. *NIX commands do things without asking. Your computer serves you, not the other way around. If I wanted my computer to double check everything that I do, I'd run Windows. "(y/n/a)" just leads to awkward shell scripts.

mhansen 17y ago
Put a '-f' in your shell script, to force the overwrite
- steveklabnik 17y ago
  Why don't you put a '--double-check-my-command' on yours?
  - mey 17y ago
    There is such a thing are reasonable defaults. This is an issue of command lines as interfaces and as tool integration points. You have reasonable defaults for both audiences. (My preference is the err on the side of the human interaction because CPU's are cheap)
    - jwhite 17y ago
      Git is unashamedly a power tool, for power users. Git checkout seems so natural to me in the way it functions, and I use it so often, that it would annoy the hell out of me if I had to force it or answer a y/n prompt every time I used it. What you think of as intuitive is not universal. Your reasonable defaults are unreasonable to me. This seems to be a problem of audience. Git can be challenging to learn, but it's not aimed at learners. It's aimed at power users. As others have pointed out, there are other front-ends to git. You don't have to use the default porcelain.
      - mey 17y ago
        Fair enough

ErrantX 17y ago

Without wanting to add fuel to the fire (really), I always think Git tries to do far too much. I think SCM should just gracefully version your code in as simple a way as possible. I went from SVN to Git a while ago and it was a great improvement. Then a friend pointed me at mercurial and I just felt it was a revolution. Finally my code felt portable. With all that said Git has some great tools for large and complex projects with many contributors. The one thing that sells HG to me though is it's insistence on non-destructiveness. If you made changes to files it always reminds me to merge changes properly without overwrites. I cant recall how many times that has saved me a n hours work :)

masklinn 17y ago
FWIW, if you want simple (as far as concept & interface go anyway) check out darcs. It probably has the simplest, sanest and sexiest (CL) interface of all modern DVCS (Git, Mercurial, Bazaar, Darcs, …). Plus because of the concepts behind it, cherrypicking is Simply Trivial. Of course, the downside is that those concepts generate other issues.
- ErrantX 17y ago
  thanks, I'll look into that.

senthilnayagam 17y ago

git porcelain is not ready for newbies, use tortoisegit or other gui interfaces. I dont understand why people should have uncommitted changes for days Branching is cheap and local, commits are local, no need to expose private work until it is ready to be merged with master, team accessible branches.

dlsspy 17y ago

> You can’t merge upstream changes into your local, uncommitted modifications No, you can't, and I'd be horrified if I ever worked in a system that did that again. First, there's never an excuse to not commit. What you commit is not necessarily what you publish. rebase -i to clean up artifacts of the junk you've done if you're worried about it (I always do it that way). But more importantly, when I pull code and what ends up is worse than what I had before, I'd like to go back to where I was.

Oxryly 17y ago
Agreed. I avoid merging (potentially extensive) outside changes/commits into my modified local files. It always seemed like a risky and unwise procedure in CVS and Perforce. I think Git's alternative of stash, pull, pop is an improvement. That way I can fix conflicts properly at each stage, and handle big changes before reapplying my hacked up stuff.

etherael 17y ago

> You can’t merge upstream changes into your local, uncommitted modifications If you're just hacking around, shouldn't the procedure be to have a branch specifically for that and keep master clean for urgent work? Confused.

jwhite 17y ago
Agreed. Local topic branch for experimental hacks. Rebase it when you want to integrate upstream changes.
- moe 17y ago
  I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. Hacking just happens. We try this and that, something works and gets committed, something else doesn't and gets reverted. My working copy is littered with uncommited files nearly constantly, simply because I work and play on many things in parallel and committing every time I save a file would be a noticable overhead, just as merging between topic branches all day. I'm not complaining, we get along, my working copy and I, but I agree in some situations git could be more helpful than "xxx needs update" - and that's really just one symptom of many. I've been playing with mercurial a bit recently (yes, heresy) and can see why the git guys despise it, it's just not as pure. The main thing that stuck with me though, is that even though it's roughly comparable to git in terms of features, it is mindboggingly much more intuitive to use. Git could take a lesson from that and would not even have to give up much of the purity. Yes, "everything" should still be possible - but they damn sure could make the beaten paths a bit less spikey.
  - dlsspy 17y ago
    > I have sympathy for the author insofar as some people (myself included) don't plan ahead that way. I don't either. I pretty much always work on master. If I find myself down a deep path that should've been a topic branch, I make one then and reset my master back to origin. > I've been playing with mercurial a bit recently (yes, heresy) and can see why the git guys despise it, it's just not as pure. The main thing that stuck with me though, is that even though it's roughly comparable to git in terms of features I used hg heavily for a long time before ever touching git. I did a bit of work on an older project that used hg recently and found myself unable to figure out how to do something I often easily do in git. I don't remember the exact details, but I ended up committing and tagging after doing a "trivial" change that ended up being wrong (I noticed before pushing). Rather than pollute my public history with garbage, I just wanted to undo the mess and go back and fix the brokenness and retag. When I used hg heavily, I was very well-versed with the ins and outs of mercurial queues for doing simple fixups like this. Not having used it recently, I had to go to the manual because I couldn't remember which combination of q-commands would do a simple effective rebase. I was especially sensitive here because the last time I was a heavy hg user, I did lose changes to queues because hg doesn't have anything like the wonderful safety net of reflog to allow me to just put my tree back in a prior stat and let me try a complicated merge/rebase again.

jrockway 17y ago

This article had a lot of potential, but misses the key points. What this article should say is: 1. Git needs a shared-library interface, so that interfaces to git can be built without quoting and parsing (the two most error-prone operations in computing). 2. Git's default scripts are a mix of shell, perl, and C that all parse command-line options in their own unique way. Eventually you find what works, but it's by random experimentation rather than by noticing patterns. 3. Git's default scripts are bloated. Quick, how many different ways are there to rebase ("git rebase", "git pull --rebase", ...) or fetch ("git fetch", "git remote update", ...)? Since the code is not necessarily shared, these operations may not even be exactly the same... just mostly the same. Basically, git is the best version control system available -- but that doesn't mean it's not a software engineering nightmare. It is. ("So why don't you fix this?", you ask? Easy: git works so well that this theoretical annoyance is very low on my list of things to fix. In a perfect world, all software would be beautiful snowflakes. In the real world, there's always something that needs even more fixing.)

dlsspy 17y ago
> 1. Git needs a shared-library interface, so that interfaces to git can be built without quoting and parsing (the two most error-prone operations in computing). Every special tool I've ever wanted to create in git I've been able to do with pipes in either shell scripts or python scripts using data export options generally used by the porcelain. People have built good APIs on top of this, and in a few cases built direct object access interfaces, but I stopped thinking library access was important when I started actually writing tools.

technomancy 17y ago

I use git every day via Magit (http://zagadka.vm.bytemark.co.uk/magit/ http://zagadka.vm.bytemark.co.uk/magit/), which is a joy to use. But every time I have to fall back to the shell for something nontrivial it just feels so awkward.