Elijah Newren <new...@gmail.com> writes:
>> +Updates files in the working tree to match the version in the index
>> +or the specified tree.
>> +
>> +'git restore-files' [--from=<tree-ish>] <pathspec>...::
>
> <tree-ish> and <pathspec>? I understand <commit-ish> and <pathspec>,
> or <tree-ish> but have no clue why it'd be okay to specify <tree-ish>
> and <pathspec> together. What does that even mean?
I have this tree object v2.6.11-tree that is not enclosed in a
commit object. I want to take the top-level Makefile out of that
tree, stuff it in the index and overwrite the working tree file.
$ git checkout v2.6.11-tree Makefile
$ git restore-files --from=v2.6.11-tree Makefile
>> + Overwrite paths in the working tree by replacing with the
>> + contents in the index or in the <tree-ish> (most often a
>> + commit). When a <tree-ish> is given, the paths that
>> + match the <pathspec> are updated both in the index and in
>> + the working tree.
>
> Is that the default we really want for this command? Why do we
> automatically assume these files are ready for commit? I understand
> that it's what checkout did, but I'd find it more natural to only
> affect the working tree by default. We can give it an option for
> affecting the index instead (or perhaps in addition).
Oooah. Now this is getting juicy.
I do think supporting "--index" (which would make it more in line
with what Duy wrote), with optionally "--cached" as well, and making
the "working tree only" mode as default may not be a bad idea. I am
offhand not sure how the "working tree only" mode (similar to the
default mode of "git apply" that mimics the way "patch -p1" works)
should interact with the non-overlay mode of the command, but other
than that, I tend to agree with the idea that restore-files is only
a part of making the contents into committable shape, not exactly
ready for it yet.
