Brandon McCaig <bamccaig@xxxxxxxxx> writes:
> Unlike a merge, when you pop a stash that history is lost. If you
> screw up the merge and the stash is dropped then there's generally no
> reliable way to get it back. I think that it's correct behavior for
> the stash to not be dropped if the merge conflicts.
Agreed.
> If there's any change that should be made it should be purely
> providing more detailed instructions to the user about how to deal
> with it.
Yes, there may be room for improvement, but that does not seem so easy.
Today, we have:
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
$ git status
On branch master
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: foo.txt
=> The advices shown here are OK. Then:
$ git add foo.txt
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: foo.txt
=> here, "git status" could have hinted the user "you may now run 'git
stash drop' if you are satisfied with your merge".
An obvious issue is that at this point Git has no way to know that you
just did a "git stash pop". But that could be solved by leaving a file
around like .git/stash-pop-ongoing.
Now, the real question is: when would Git stop showing this advice. I
don't see a real way to answer this, and I'd rather avoid doing just a
guess.
One easy thing to do OTOH would be to show a hint at the end of "git
stash pop"'s output, like
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
'stash pop' failed. Please, resolve the conflicts manually. The stash
was not dropped in case you need to restart the operation. When you are
done resolving the merge, you may run the following to drop the stash:
git stash drop
or so (I couldn't find a concise yet accurate wording).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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