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

From: Duy Nguyen <pclouds@gmail.com>
Date: May 7, 2019, 10:36 UTC
Message-ID: <CACsJy8DSVJuwNWfEcA1pv1vdoCn=EKTmhBncRtKLZedQiEj0AA@mail.gmail.com>
In-Reply-To: <20190507022127.GA220818@google.com>

On Tue, May 7, 2019 at 9:21 AM Emily Shaffer <emilyshaffer@google.com> wrote:

> I've got a usability comment, as we're giving restore a try within
> Google for now.

Thanks. I thought I was the only guinea pig :D and obviously not a good one since I know too much (which is not a good thing as a tester).

Show 8 quoted lines

> 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.

For the record, "git restore --staged :/" should do the trick and it is documented as an example (but without --staged).

Either way. I think you raise a good point about "*" (or patterns matching more than expected in general). I need to sleep on it and see if the old way of handling pattern matching failure is still a good way to go.

> 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).

For just a couple files, you could also use "-p" to go through them and either "a" to restore all or "d" to skip the file. Maybe adding "-i/--interactive" to git-restore too, just like "git add". Hmm...

-- 
Duyh