On Tue, Feb 19, 2019 at 9:42 PM Elijah Newren <new...@gmail.com> 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....@gitster-ct.c.googlers.com/ > > Elijah -- Duy
