Re: [PATCH v2 00/16] Add new command 'restore'

From: Duy Nguyen <pclouds@gmail.com>
Date: Apr 13, 2019, 10:39 UTC
Message-ID: <CACsJy8A42eObPkDvuPd7GodKxfaRMk0cd1YLUz+G-K4Qed2X7Q@mail.gmail.com>
In-Reply-To: <xmqq4l73ztxf.fsf@gitster-ct.c.googlers.com>

On Fri, Apr 12, 2019 at 12:14 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 8 quoted lines

> > - git-rm learns about --staged as an alias of --cached (in fact it's
> >   more the other way around). This is to keep suggestions consistent
> >   because we tell people to do "git foo --staged" everywhere.
>
> I am not sure 100% about this one.  If "--staged" is only about
> updating the index without touching the working tree, then existing
> "--cached" is already serving its purpose and there is no need to
> add yet another.

It's so we suggest the same option name in "git status" instead of

 - git add/rm/retore <paths>
 - git restore [--source] --staged <paths>
 - git rm --cached <paths>

It's in the name of consistency but perhaps it's just not worth it? It could also be seen as the continuation of adding --staged [1]

[1] https://public-inbox.org/git/1225296936-1357-1-git-send-email-dsymonds@gmail.com/

Show 5 quoted lines

> Why did we need it for "restore-paths" in the
> first place?  Is it because the target of restoring can be one of
> the three (index+working-tree, index-only, or working-tree only),
> not just the traditional two (index+working-tree that is signalled
> by "--index", and index-only that is signalled by "--cached")?

Yes.

> I think it would make sense to introduce --staged to "git rm", if we
> teach the third target (i.e. "working-tree only") to the command,
> but otherwise, I am not sure if it would help reducing conflusion.

I could add that. "git rm --worktree" then is almost like "rm" except that only tracked paths are affected. The default target of "git rm" is still "both worktree and index" though. I don't think we can ever change that (e.g. to match "git restore" which defaults to worktree only)

-- 
Duy