From: Junio C Hamano Date: Tue, 04 Dec 2018 03:33:16 GMT Subject: Re: [PATCH v3 07/14] checkout: split into switch-branch and restore-files Message-ID: In-Reply-To: Elijah Newren writes: >> +Updates files in the working tree to match the version in the index >> +or the specified tree. >> + >> +'git restore-files' [--from=] ...:: > > and ? I understand and , > or but have no clue why it'd be okay to specify > and 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 (most often a >> + commit). When a is given, the paths that >> + match the 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.