On Mon, 15 Mar 2010, Junio C Hamano wrote:
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.
This is an interesting use-case. If you determine that your resolution
is satisfactory, how then do you complete your merge? You can't apply a
stash on a dirty index, and the MERGE_* files are gone. It seems like
using this workflow to "pause" and resume a merge is difficult, although
it's exactly the thing that led to this patch in the first place. Maybe
git-stash could hold onto those files somehow if they exist when saving?
--
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