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.
