> 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.
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.
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.
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?
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.
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.)
> 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.
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 :)
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.
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.
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?
> …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.
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.
I use git every day via 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.
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'.
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?
[+] [-] dlsspy|16 years ago|reply
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|16 years ago|reply
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.
[+] [-] stevejohnson|16 years ago|reply
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|16 years ago|reply
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?
[+] [-] davepeck|16 years ago|reply
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|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
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|16 years ago|reply
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.
[+] [-] ErrantX|16 years ago|reply
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|16 years ago|reply
Plus because of the concepts behind it, cherrypicking is Simply Trivial.
Of course, the downside is that those concepts generate other issues.
[+] [-] kinghajj|16 years ago|reply
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|16 years ago|reply
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?
[+] [-] steveklabnik|16 years ago|reply
*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|16 years ago|reply
[+] [-] mjgoins|16 years ago|reply
[+] [-] senthilnayagam|16 years ago|reply
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.
[+] [-] technomancy|16 years ago|reply
[+] [-] etherael|16 years ago|reply
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|16 years ago|reply
[+] [-] MarkPNeyer|16 years ago|reply
[+] [-] m0th87|16 years ago|reply
[+] [-] superjared|16 years ago|reply
[+] [-] davidw|16 years ago|reply
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?
[+] [-] johnbender|16 years ago|reply