Duy Nguyen <pclouds@xxxxxxxxx> writes: > Elijah wanted another mode (and I agree) that modifies worktree but > leaves the index alone. This is most useful (or least confusing) when > used with <tree-ish> and would be default in restore-files. I'm not > saying you have to implement it, but how do the new command line > options are designed to make sense? I'd model it after "git apply", i.e. git restore-files [--tree=<treeish>] <pathspec> would work only on the working tree files, git restore-files --tree=<treeish> --cached <pathspec> would match the entries in the index that match pathspec to the given treeish without touching the working tree, and git restore-files --tree=<treeish> --index <pathspec> would be both. I have never been happy with the phraso, the (arbitrary) distinction between --cached/--index we use, so in the very longer term (like, introducing synonym at 3.0 boundary and deprecating older ones at 4.0 boundary), it may not be a bad idea to rename "--index" to "--index-and-working-tree" and "--cached" to "--index-only". But until that happens, it would be better to use these two consistently.
