Duy Nguyen <pclo...@gmail.com> 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.
