Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > lists@xxxxxxxxxxxxxxxx (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 guessing. > 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 :). -- -- Stephe -- 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