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

From: Emily Shaffer <emilyshaffer@google.com>
Date: May 7, 2019, 02:21 UTC
Message-ID: <20190507022127.GA220818@google.com>
In-Reply-To: <20190425094600.15673-1-pclouds@gmail.com>

Hiya,

On Thu, Apr 25, 2019 at 04:45:44PM +0700, Nguyễn Thái Ngọc Duy wrote:

Show 27 quoted lines

> 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