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

[Emily Shaffer <emilyshaffer@google.com>]

On Tue, May 07, 2019 at 05:36:56PM +0700, Duy Nguyen wrote:
> 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).
> 
> > 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).

Yeah, this worked, and today I also noted `git restore --staged .`
works, as does Junio's suggestion on the other mail (`git restore
--staged revision.\*`), and quoting the * (`git restore --staged '*'`).
So maybe I didn't think outside the box enough before mailing :)

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

I think it's worth considering, especially as `git reset HEAD *` and
`git reset HEAD` both work. (`git restore --staged` complains that it
hasn't got any paths, but reset seems to figure you just mean
everything.) It was a surprising failure to me coming away from years of
using reset.

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

Anyways, maybe it's not a particularly weighty complaint, since there
are still ways to mass unstage, and if I had just RTFM I would have
found them. :) It's a new workflow, after all, and the old one still
works, so it's probably not reasonable to expect it all to just work the
same way with s/reset HEAD/restore --staged/.

Thanks!
 - Emily