On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
<> 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

 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.


Brandon McCaig <> <>
Castopulence Software <>
Blog <>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to