Hiya, On Thu, Apr 25, 2019 at 04:45:44PM +0700, Nguyễn Thái Ngọc Duy wrote: > 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
