On Mon, Apr 24, 2017 at 4:33 PM, Philip Oakley <philipoak...@iee.org> wrote:
> This is almost the same as just reported by 'vvs' [1] > https://public-inbox.org/git/CAM1zWBtfgHT=pT0pidQo1HD=dfrxlg3gnauvs0vzkvyfg1b...@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: >> 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.ca...@gmail.com/ 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. >