3 ms·

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

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?

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?