Stephan: On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake <stephen_leake@xxxxxxxxxxxxxxxx> wrote: > You might be adding other files for other reasons. But if you add a file > that does resolve a conflict caused by 'git stash pop', it is not > guessing. Staging a file doesn't tell git that you resolved a conflict. Git will happily accept a blob full of conflict markers. Git doesn't know the difference. Git expects the user to know what is right. The user has the freedom to manipulate the index as they see fit, which means both adding and removing from it anytime they wish. > So "git add" and "git stash *" are lower level tools; to get the effect > we are asking for, we should use a front-end (which is why I'm writing > one for Emacs :). You *can* use a front end, but I would argue that you shouldn't necessarily. Most third-party front ends only serve to confuse users. In general, they only cause problems and encourage ignorance. Git is a very pure system. It doesn't impose too may rules on you. It basically just gives you the tools that you need to work within the system and gets out of your way. It is up to the user to learn how to assemble those tools for good (and many front ends exist to help; sometimes arguably too many as it is, such as git-pull(1) for example). This isn't a case of the API being wrong. This is a case of PEBKAC, IMO. Maybe the API can be a little bit more verbose in assisting the user to understand what has happened and what sensible options there are, but we should avoid catering to newbies too much. You should only be a newbie for a short time. After that you should begin to learn the API. Hand holding at that point would be noise (as it would for most of us here, I imagine). The worst kind of "hand holding" is the kind that imposes rules on you that aren't universal. Dropping the stash after adding all changes to the index after a failed pop is not universal. At most, git stash pop should give the user a bit more guidance to understand what the situation is. At least, the user should RTFM and learn to use the tools. And that might involve some mistakes, but you learn from mistakes. At least Git does a good job of making it easy to recover from most of your mistakes. The proposed change to git-add takes away one of those safety nets. Git isn't always the easiest thing to wrap your head around, but I have found that once you have wrapped your head around it Git is the easiest thing to get the job done the way you want. I consider the learning curve a strength of Git. Which isn't to say that there isn't room for improvement, but when proposing improvements we should try to make sure that they actually make things universally better. Regards, -- Brandon McCaig <bamccaig@xxxxxxxxx> <bamccaig@xxxxxxxxxxxxxxxx> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bamccaig.com/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say' -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html