Re: [PATCH] restore: fault --staged --worktree with merge opts

From: Andy Koppe <andy.koppe@gmail.com>
Date: Feb 21, 2023, 22:27 UTC
Message-ID: <CAHWeT-Zy=iJZoVAWZHqnGGFb-KMbg1fk_mmdE2T=K4+xRHpG0A@mail.gmail.com>
In-Reply-To: <xmqqa616g8yv.fsf@gitster.g>

On Tue, 21 Feb 2023 at 18:38, Junio C Hamano wrote:

>         Side note 2: it is conceivable that --worktree --staged
>         --ours may want to (1) resolve the conflicted path to stage
>         #2 in the index and (2) check out the result in the working
>         tree.

Same with restore --worktree --staged --theirs and stage #3?

That's basically what I thought these combinations would do when I noticed that they were accepted. I think they would be quite convenient compared to separate restore and add. They'd be the equivalent of 'svn resolve --accept=mine-full/theirs-full'.

>         But until such an improved behaviour gets
>         implemented, it is probably better to error it out for now.

Indeed. Unfortunately implementing that improvement is beyond my knowledge of git internals.

>> +test_expect_success 'restore with merge options rejects --staged' '
>> +     test_must_fail git restore --staged --merge . -- 2>err1 &&

> What is "." meant to be on this command line?  If it is "the whole
> working tree", it should come after the double-dash "--", no?

Sorry, that was accidental. The command requires a path argument to get to the option conflict error, but as you say, putting it before the "--" doesn't make sense.

Thank you very much for the thorough review. I'll prepare a new version of the patch.