git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Andy Koppe <andy.koppe@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2] restore: fault --staged --worktree with merge opts
Date: Mon, 27 Feb 2023 17:02:23 -0800	[thread overview]
Message-ID: <xmqqmt4yr49s.fsf@gitster.g> (raw)
In-Reply-To: <20230226184354.221-1-andy.koppe@gmail.com> (Andy Koppe's message of "Sun, 26 Feb 2023 18:43:54 +0000")

Andy Koppe <andy.koppe@gmail.com> writes:

> +	/*
> +	 * Reject --staged option to the restore command when combined with
> +	 * merge-related options. Use the accept_ref flag to distinguish it
> +	 * from the checkout command, which does not accept --staged anyway.

Understandable.

> +	 * `restore --ours|--theirs --worktree --staged` could mean resolving
> +	 * conflicted paths to one side in both the worktree and the index,
> +	 * but does not currently.

Understandable, especially with an understanding that "does not
currently" hints our wish to eventually support it.

> +	 * `restore --merge|--conflict=<style>` already recreates conflicts
> +	 * in both the worktree and the index, so adding --staged would be
> +	 * meaningless.

And from the same line of reasoning, I do not know if this is a good
idea.  If "--merge|--conflict=<style>" should recreate conflicts in
both when given to "restore --staged --worktree", and if it does so
already, then shouldn't it be simply allowed?

Why would it be meaningless?

Now, it may be understandable to say that it is meaningless to ask
merge conflict recreated only in the working tree file but not in
the index, or done only in the index but not in the working tree,
and erroring out such a request might make sense, but even then, if
we do not plan to change the behaviour in the future when "restore
--staged --merge" without "--worktree" from what we currently do, I
am not sure if it makes sense to error out such a "meaningless"
request.

Or perhaps I misunderstood the conditional below?

> +	 */
> +	if (!opts->accept_ref && opts->checkout_index) {
> +		if (opts->writeout_stage)
> +			die(_("'%s' or '%s' cannot be used with %s"),
> +			    "--ours", "--theirs", "--staged");
>  
> -	if (opts->checkout_index && !opts->checkout_worktree &&
> -	    opts->merge)
> -		die(_("'%s' or '%s' cannot be used with %s"),
> -		    "--merge", "--conflict", "--staged");
> +		if (opts->merge)
> +			die(_("'%s' or '%s' cannot be used with %s"),
> +			    "--merge", "--conflict", "--staged");
> +	}

> diff --git a/t/t2070-restore.sh b/t/t2070-restore.sh
> index 7c43ddf1d9..c5d19dd973 100755
> --- a/t/t2070-restore.sh
> +++ b/t/t2070-restore.sh
> @@ -137,4 +137,20 @@ test_expect_success 'restore --staged invalidates cache tree for deletions' '
>  	test_must_fail git rev-parse HEAD:new1
>  '
>  
> +test_expect_success 'restore with merge options rejects --staged' '
> +	for opts in \
> +		"--staged --ours" \
> +		"--staged --theirs" \
> +		"--staged --merge" \
> +		"--staged --conflict=diff3" \
> +		"--staged --worktree --ours" \
> +		"--staged --worktree --theirs" \
> +		"--staged --worktree --merge" \
> +		"--staged --worktree --conflict=zdiff3"
> +	do
> +		test_must_fail git restore $opts . 2>err &&
> +		grep "cannot be used with --staged" err || return
> +	done
> +'

It is quite clear what cases are (and are not) being tested here
when written this way.

Thanks.

      reply	other threads:[~2023-02-28  1:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18 16:39 [PATCH] restore: fault --staged --worktree with merge opts Andy Koppe
2023-02-21 18:38 ` Junio C Hamano
2023-02-21 22:27   ` Andy Koppe
2023-02-22 23:09     ` Junio C Hamano
2023-02-26 18:43       ` [PATCH v2] " Andy Koppe
2023-02-28  1:02         ` Junio C Hamano [this message]

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqqmt4yr49s.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=andy.koppe@gmail.com \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).