On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley <philipoakley@xxxxxxx> wrote: > This is almost the same as just reported by 'vvs' [1] > https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=DfrXLG3gNaUvs0vZKvYfG1BHFw@xxxxxxxxxxxxxx/, > 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: >> 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? > It also has a similarity to > https://public-inbox.org/git/1492287435.14812.2.camel@xxxxxxxxx/ regarding > how checkout operates. This seems to be orthogonal to the original topic (no submodules, nor checkout bugs, just a doc update?) > 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. >