Dave Olszewski <cxreg@xxxxxxxxx> writes:
> Similar to commit c8c562a, if a user is resolving conflicts, they may
> think it wise to stash their current work tree and git pull to see if
> there are additional changes on the remote.
>
> The stash will fail to save if the index contains unmerged entries, but
> if the conflicts are resolved, the stash will succeed, and both
> MERGE_HEAD and MERGE_MSG will be removed. This is probably a mistake,
> and we should warn the user and refuse to stash.
Warning is probably Ok, but refusing with die() might be too much.
When trying a topic with more than one integration branches (think
"master", "next, "pu"), and the merge is a bit too hairy that I am not
very confident with the resolution, I've deliberately used stash to record
a tentative conflict resolution to avoid contaminating my rerere database:
$ git merge topic
... heavy conflicts, manually "resolved" to a dubious result ...
$ git rerere clear
$ git stash save "tentative merge of topic"
$ git stash apply
... test test test ...
$ git reset --hard
$ git checkout another-integration-branch
$ git stash apply
... test test test ...
... repeat the above for other integration branches ...
This is using the stash as a glorified form of
$ git diff HEAD >./+save-tentative-merge
and then applying it to other integration branches to test out
$ git reset --hard
$ git checkout another-integration-branch
$ git apply ./+save-tentative-merge
but it actually is better than diff/apply because stash application uses a
real three-way merge.
So I am not entirely happy with this feature-removal.
--
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