Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
> li...@haller-berlin.de (Stefan Haller) writes:
>> Your intention was clearly to drop the stash, it just wasn't dropped
>> because of the conflict. Dropping it automatically once the conflict
>> is resolved would be nice.
> Your intention when you ran "git stash pop", yes. Your intention when
> you ran "git add", I call that guessing.
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
> The condition for dropping the stash should be more "conflits
> resolutions are done AND the user is happy with it". Otherwise, if you
> mess up your conflict resolution, and notice it after running "git add",
> then you're screwed because Git just happily discarded your important
> data. The point of keeping the stash is to leave it up to the user to
> decide between "I'm happy, I can drop" or "I'm not, I should re-apply",
> and Git cannot tell which is which.
Yes, that makes sense.
> Hinting the user to run "stash pop" would be more acceptable, but
> talking about "git stash" in "git add"'s code is somehow a dependency
> order violation (stash is normally implemented on top of Git's basic
> features, not the other way around). Does not seem serious from at first
> from the user point of view, but this pushes the codebase one step in
> the direction of an unmaintainable mess.
Also makes sense.
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 :).
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html