Re: Submodule/contents conflict

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 28, 2017, 02:08 UTC
Message-ID: <xmqq37ctmgh6.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <DAB03BFCBBCA4C4F95D21A86E3B1DF2F@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 5 quoted lines

>> In the modern day, it might be useful if the "--working-tree-only"
>> mode added a new file as an intent-to-add entry to the index, but
>> that is not what "git apply (no other options)" (which is the gold
>
> did you mean `git add` ? Or am I missing something.

I did mean "git apply" that applies the patch (0) only to the working tree by default, (1) to the index without touching the working tree with the "--cached" option and (2) both to the working tree and the index with the "--index" option. As "git add" is all about the index, having these three modes wouldn't make much sense there.

Show 10 quoted lines

>> +'git checkout' --working-tree-only <tree-ish> [--] <pathspec>...::
>> + Similar to `git checkout <tree-ish> [--] <pathspec>`, but
>> + the index file is left in the same state as it was before
>> + running this command.
>
> I feel that the docs should also contain a little of the commit
> message highlighting that `This complements the usual convention of
> "--cached" and "--index" options for other commands.`, and would pick
> up on Stefan's "I didn't know that" response - A little education of
> the reader goes a long way, maybe ;-)

I do not think "If we were building Git from scratch today without having any existing user of `git checkout`, we probably would have made this to be the default mode of operation, and instead required the user to say `git checkout --index <tree-ish> <pathspec>' if the user wants checkout to affect both the index and the working tree, to be more consistent with other parts of the system" would help the readers of the current system very much, even if we were promising that such a more consistent system may come in a future (and we are not, at least not yet, with this addition).