git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Denton Liu <liu.denton@gmail.com>,
	Felipe Contreras <felipe.contreras@gmail.com>,
	Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH 4/4] merge: apply autostash if merge strategy fails
Date: Fri, 23 Jul 2021 12:22:34 -0700	[thread overview]
Message-ID: <xmqqk0lgn8cl.fsf@gitster.g> (raw)
In-Reply-To: <e02b945ce8595a8d7b1b4ad9c382a1beeb040ed4.1627042470.git.gitgitgadget@gmail.com> (Philippe Blain via GitGitGadget's message of "Fri, 23 Jul 2021 12:14:30 +0000")

"Philippe Blain via GitGitGadget" <gitgitgadget@gmail.com> writes:

> As explained in a03b55530a, and made more abvious by the tests added in
> that commit, the autostash is then applied if the merge succeeds, either
> directly or by committing (after conflict resolution or if '--no-commit'
> was given), or if the merge is aborted with 'git merge --abort'. In some
> other cases, like the user calling 'git reset --merge' or 'git merge
> --quit', the autostash is not applied, but saved in the stash list.

OK.

> However, there exists a scenario that creates an autostash but does not
> apply nor save it to the stash list: if the chosen merge strategy
> completely fails to handle the merge, i.e. 'try_merge_strategy' returns
> 2.
>
> Apply the autostash in that case also. An easy way to test that is to
> try to merge more than two commits but explicitely ask for the 'recursive'
> merge strategy.

We know that the recursive that barfs when asked to merge more than
one "other" histories will fail before touching the index or the
working tree, but I do not think the merge-strategy protocol makes
any guarantee as to what half-modified state the strategy would
leave the index and the working tree in.

So this change at the first glance looks risky, but at least we have
a call to restore_state() before you added an apply_autostash().
The restore_state() call is the same as the one is used between
application of a strategy that has failed the same way in the loop,
so we should be able to trust it to bring the state back to the
pristine (i.e. after autostash removed the local changes).

I think this change makes sense, too.

(I didn't look at 1/4 and 2/4)

Thanks.



> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com>
> ---
>  builtin/merge.c  | 1 +
>  t/t7600-merge.sh | 8 ++++++++
>  2 files changed, 9 insertions(+)
>
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 788a6b0cd55..d44c14a21a3 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -1709,6 +1709,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
>  		else
>  			fprintf(stderr, _("Merge with strategy %s failed.\n"),
>  				use_strategies[0]->name);
> +		apply_autostash(git_path_merge_autostash(the_repository));
>  		ret = 2;
>  		goto done;
>  	} else if (best_strategy == wt_strategy)
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 216113d3537..2ef39d3088e 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -732,6 +732,14 @@ test_expect_success 'octopus merge with --autostash' '
>  	test_cmp result.1-3-5-9 file
>  '
>  
> +test_expect_success 'failed merge (exit 2) with --autostash' '
> +	git reset --hard c1 &&
> +	git merge-file file file.orig file.5 &&
> +	test_must_fail git merge -s recursive --autostash c2 c3 2>err &&
> +	test_i18ngrep "Applied autostash." err &&
> +	test_cmp result.1-5 file
> +'
> +
>  test_expect_success 'conflicted merge with --autostash, --abort restores stash' '
>  	git reset --hard c3 &&
>  	cp file.1 file &&

  reply	other threads:[~2021-07-23 19:22 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-23 12:14 [PATCH 0/4] [RFC] merge --autostash: apply autostash in more cases Philippe Blain via GitGitGadget
2021-07-23 12:14 ` [PATCH 1/4] merge: add missing word "strategy" to a message Philippe Blain via GitGitGadget
2021-07-23 15:57   ` Felipe Contreras
2021-07-23 12:14 ` [PATCH 2/4] Documentation: define 'MERGE_AUTOSTASH' Philippe Blain via GitGitGadget
2021-07-23 16:00   ` Felipe Contreras
2021-07-23 12:14 ` [PATCH 3/4] merge: apply autostash if fast-forward fails Philippe Blain via GitGitGadget
2021-07-23 16:02   ` Felipe Contreras
2021-07-23 19:13   ` Junio C Hamano
2021-07-23 12:14 ` [PATCH 4/4] merge: apply autostash if merge strategy fails Philippe Blain via GitGitGadget
2021-07-23 19:22   ` Junio C Hamano [this message]
2021-07-23 16:10 ` [PATCH 0/4] [RFC] merge --autostash: apply autostash in more cases Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqk0lgn8cl.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=liu.denton@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).