Re: Submodule/contents conflict

From: "Stefan Beller" <redacted>

On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley [off-list ref] 
wrote:

quoted

This is almost the same as just reported by 'vvs' [1]
https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=DfrXLG3gNaUvs0vZKvYfG1BHFw@mail.gmail.com/,
originally on the 'git user' list
https://groups.google.com/forum/?hl=en#!topic/git-users/9ziZ6yq-BfU

For this issue, +cc Jeff King due to this pointer:

quoted

quoted

On the main list thare is a similar "issue" [1] regarding the 
expectation for `git checkout`,
and importantly (for me) these collected views regarding the "Git Data 
Protection and
Management Principles" is not within the Git documentation.

Yes, that's an interesting point. What concerns me is that the commit
c5326bd62b7e168ba1339dacb7ee812d0fe98c7c which introduced this
into checkout isn't consistent with reset. Seems that nobody noticed this 
before.

It seems as if we'd want to see the code from
c5326bd62b7e168ba1339dacb7ee812d0fe98c7c
to be part of any worktree touching command, specifically reset?

quoted

It also has a similarity to
https://public-inbox.org/git/1492287435.14812.2.camel@gmail.com/ 
regarding
how checkout operates.

This seems to be orthogonal to the original topic (no submodules, nor 
checkout
bugs, just a doc update?)

At the moment that topic has ended up as an attempt at a documentation 
update, but I think it may not succeed ynless there is clarity about the 
(reported) underlying problem.

As I recall Christoph was using checkout to copy a file (e.g. a template 
file) from an older commit/revision into his worktree, and was suprised that 
this (git checkout <tree> <path>) also _staged_ the file, rather than simply 
letting it be in a modified/untracked state.

It in a sense is the same issue of relating the worktree content to the 
index status, though I think that checkout is acting as designed/intended. 
I don't think that there is a command (is ther?) to do what Christoph hoped 
for of not staging the new content (e.g. a template file), but the index 
knowing/remembering its stat details, just in case.

The submodule case appears to be more about deciding if the content of 
submodule's index should be considered for inclusion in the super project 
prior to the checkout of the other branch's tree that is already unchanged 
and in-place.

quoted

It does feel as if there are two slightly different optimisations that 
could
be used when the desired file pre-exists in the worktree, but isn't
immediately known to the index.

--
Philip