On Tue, Feb 19, 2019 at 9:42 PM Elijah Newren <newren@xxxxxxxxx> wrote:
> > OK this hopefully will be the final design
> >
> > (git restore) "[--worktree] <paths>" restores worktree paths from index
> >
> > "--index <paths>" restores the index from HEAD (aka "git reset")
> >
> > "--source <tree> (--index|--worktree) <paths>" restores index or
> > worktree (or both) from <tree>
> >
> > I'm a bit reluctant to support "git restore --index --worktree
> > <paths>" without --source, which should default to HEAD, since it's a
> > bit unclear/inconsistent ("git restore --worktree <paths>" defaults to
> > index as the source, but here we use a different default source).
>
> Sorry for going missing a while from the conversation, and thanks so
> much for pushing this forward.
>
> Overall this looks good, but there's just one part that confuses me.
> Here you seem to suggest that if you pass --source but neither --index
> or --worktree that both the index and working tree will be written to.
No no. Sorry for not being clear. If neither --index or --worktree is
given, the default will be --worktree. --source changes the "source"
but cannot influence target selection. So "git restore --source=HEAD
foo.c" will restore foo.c on the worktree but not the index. I still
remember that point you and Stefan Xenos raised ;-)
Full git-restore.txt is here if you're interested. I think I'll send
it out soon once git-switch part more or less settles.
https://gitlab.com/pclouds/git/blob/switch-and-restore-forever/Documentation/git-restore.txt
> Why are "restored" changes considered ready for commit? That seems
> confusing to me (and was one of the bugs of checkout, IMO). See also
> second half of https://public-inbox.org/git/xmqq1s6yezk3.fsf@xxxxxxxxxxxxxxxxxxxxxxxxx/
>
> Elijah
--
Duy
