Re: Submodule/contents conflict

[Junio C Hamano <gitster@pobox.com>]

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

>> 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.

>> +'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).