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

[Emily Shaffer <emilyshaffer@google.com>]

Hiya,

On Thu, Apr 25, 2019 at 04:45:44PM +0700, Nguyễn Thái Ngọc Duy wrote:
> v3 changes are really small
> 
> - gitcli.txt is updated to mention the --staged/--worktree pair, in
>   comparison to --cached/--index which is also mention there.
> 
> - The patch 'rm --staged' is dropped. It could come back. But if it
>   does, it should be in a series where commands that take
>   --cached/--index will now take both --staged/--worktree. Those are
>   'rm', 'apply', 'check-attr', 'grep', 'diff' and maybe 'ls-files'.
>   
>   In other words we support --staged/--worktree everywhere while
>   --cached/--index still remains because of muscle memory. This is
>   of course only a good move if --staged/--worktree is much better
>   than --cached/--index.
> 
> - Since there's a chance this series may end up in 'master' and get
>   released, and I'm still worried that I screwed up somewhere, the last
>   patch declares the two commands experimental for maybe one or two
>   release cycles.
>   
>   If the reception is good, we revert that patch. If something
>   horrible is found, we can still change the default behavior without
>   anybody yelling at us. Or worst case scenario, we remove both
>   commands and declare a failed experiment.
> 
> PS. the intent-to-add support is still not in. But it should be in
> before the experimental status is removed.

I've got a usability comment, as we're giving restore a try within
Google for now. I found myself in a situation where I had accidentally
staged all my changes to tracked files (I think resulting from a stash
pop which generated a merge conflict?) and didn't see a good way to
unstage everything using restore.

I tried out `git restore --staged *` and it tried to restore every build
artifact in my working tree, all of which should be ignored, made a lot of
noisy errors, and left me with my changes still staged.

Then, figuring that I only had a few files, I thought I'd type them
each, with the exception of a .c/.h pair:

g restore --staged builtin/log.c builtin/walken.c revision.*

Because I had build artifacts present, this vomited while trying to
unstage revision.o, and again left me with all my changes still staged.
revision.o is validly ignored:

$ g check-ignore revision.o                               
revision.o

Finally explicitly naming each file which I needed to restore worked,
but I have very little interest in doing this for more than a handful of
files, especially since the output of `git status` is not easy to paste
into the command line (due to the "modified:" etc marker).

I was definitely still able to make it do what I wanted with `git reset
HEAD` but thought you may be interested. It'd be cool to have a hint
which advises how you can unstage everything, or else to pay attention
to the gitignore and not try to unstage those files, or else to have a
command to unstage everything. (I looked for one by trying `git restore
--staged -a` but that doesn't exist :) )

Thanks!
Emily