On Saturday, April 22, 2017 at 11:14:08 PM UTC+2, vvs wrote:
>
> On Saturday, April 22, 2017 at 11:28:49 PM UTC+3, Philip Oakley wrote:
>>
>> 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.
>
Interesting observation, might be worth raising on the Git mailing list[1]
as well, hopefully getting some more insight. A discussion that seems to
predate the mentioned commit[2] can be found here[3].
That said, I`m not sure the current "checkout" isn`t consistent with
"reset", but more that they both exhibit the same "glitch"(?) in certain
occasions, where the same content file is still overwritten (timestamp
updated), which does seem unexpected (as file content is unchanged, thus no
need to update the file). I wouldn`t know if it`s not some optimization
thing, though, yet it seems that performance would rather be hurt by
needlessly (re)writing unchanged files... or maybe not? But "make"-alike
systems are hurt for sure, triggering an unnecessary rebuild.
Taking your first example as a base, if we do:
(1) git reset HEAD^
(2) git checkout @{1} -- yyy
... then timestamp is updated (file overwritten), even though the
(untracked) file had the same content (both index and working tree get
updated). But if we now do this instead:
(3) git checkout @{1}
... then the "yyy" timestamp is left intact (might be due to already
updated index, same as in your "reset" case?).
So it looks like in both cases (`git checkout $tree $file` and `git reset
--hard`), if file does not exist in the index yet (it`s untracked), it gets
written out, even if the same file already exists in the working tree
(which is then needlessly overwritten, timestamp updated accordingly).
[1] [email protected]
[2] https://github.com/git/git/commit/c5326bd62b7e168ba1339dacb7ee812d0fe98c7c
[3]
https://public-inbox.org/git/[email protected]/T/#u
Regards,
Buga
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
