Re: `git stash pop` UX Problem

Stephan:

On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake <stephen_leake@stephe-leake.org> wrote:

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.

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,