On Thu, Jul 5, 2012 at 1:15 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Phil Hord <phil.h...@gmail.com> writes:
>> The presence of a GIT_DIR/MERGE_RR file indicates we
>> were resolving a merge which had rerere candidates for
>> recording.  But the file does not get deleted after
>> all resolutions are completed.  This is ok for most
>> cases because the file will get replaced when the
>> next merge happens.  But stash apply does not use
>> a merge that supports rerere, and so the old
>> MERGE_RR does not get replaced with a current one.
> Thanks for digging to the real cause.

Well, it only took me a year.

> It does use merge-recursive
> backend directly, and as a backend, it probably is correct that it
> does not invoke rerere itself.
> In your patch, you are removing the state before you check and
> notice that the user is in the middle of a merge and give control
> back with "Cannot apply a stash in the middle of a merge".  Wouldn't
> it be nicer to the user if you didn't remove the rerere state when
> this happens (i.e. the user mistakenly said "stash apply" after a
> conflicted merge), as that rerere state likely is from that merge
> that produced the conflicted state?
> Would an obvious alternative of running "git rerere" ourselves after
> running "git merge-recursive" in this script work?
>  git-stash.sh | 1 +
>  1 file changed, 1 insertion(+)
> diff --git a/git-stash.sh b/git-stash.sh
> index 4e2c7f8..bbefdf6 100755
> --- a/git-stash.sh
> +++ b/git-stash.sh
> @@ -469,6 +469,7 @@ apply_stash () {
>         else
>                 # Merge conflict; keep the exit status from merge-recursive
>                 status=$?
> +               git rerere
>                 if test -n "$INDEX_OPTION"
>                 then
>                         gettextln "Index was not unstashed." >&2

Yes, except it needs "git rerere clear".  "git rerere" is not enough
to cause the clean-up to occur.

I'll roll a patch.

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

Reply via email to