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