On Tue, May 7, 2019 at 9:21 AM Emily Shaffer <emilyshaf...@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). 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
