To summarize Torek's answer:
Torek insists on the fact git restore --source <aCommit> --worktree -- somefile
is new (cannot be done with checkout): the ability to restore a file in the working tree without touching the index.
Darren Ng adds in the comments:
Now I can discard staged changes with a single git restore --staged --worktree -- FILE
, instead of 2-step git restore --staged FILE
+git checkout FILE
.
True, but Git 2.41 (Q2 2023) makes it clear that not all options are supported when using both --staged --worktree
.
While "git restore
"(man) supports options like --ours
that are only meaningful during a conflicted merge, but these options are only meaningful when updating the working tree files.
These options are marked to be incompatible when both "--staged
" and "--worktree
" are in effect.
See commit ee8a888 (26 Feb 2023) by Andy Koppe (akoppe
).
(Merged by Junio C Hamano -- gitster
-- in commit 67076b8, 19 Mar 2023)
restore
: fault --staged --worktree
with merge opts
Signed-off-by: Andy Koppe
The 'restore' command already rejects the --merge
, --conflict
, --ours
and --theirs
options when combined with --staged
, but accepts them when --worktree
is added as well.
Unfortunately that doesn't appear to do anything useful.
The --ours
and --theirs
options seem to be ignored when both --staged
and --worktree
are given, whereas with --merge
or --conflict
, the command has the same effect as if the --staged
option wasn't present.
So reject those options with '--staged --worktree
' as well, using opts->accept_ref
to distinguish restore from checkout.
Add test for both '--staged
' and '--staged --worktree
'.