Junio C Hamano <gits...@pobox.com> writes: > Stephen Leake <stephen_le...@stephe-leake.org> writes: > >> 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 >> guessing. > > The only thing you know for sure is that the user has consumed _one_ > part of the stashed change, no? What if the stash had changes for > more than one path?
Count the unmerged paths in the index; when the count is zero, all conflicts are resolved. paths in the stash that had no conflicts are already in the index. So _if_ there is nothing going on except finishing the stash pop, an unmerged path count of zero means you are done with the stash, and it can be dropped. > At the time of "git add $path", can you reliably tell if the > conflict to the $path the user is resolving came from a previous > "git stash pop", not from any other mergy operations, e.g. "git > stash apply" or "git apply -3"? This is the real problem. I can impose a rule on my team of "don't do more than one merge at a time" by implementing that in the front-end, but git can't assume that. -- -- Stephe -- 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
