Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> Junio C Hamano venit, vidit, dixit 11.01.2016 19:19:
>> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
>>
>>> This happens whenever the "stat" information changes, e.g. due to
>>> changed device numbering and such. "git reset --hard" would have been
>>> the quickiest way to reset the stat cache/index - after git diff, of
>>> course ;)
>>
>> That does not quite explain why 'git status' reported modified files
>> in the first place. It would have refreshed the cached stat info in
>> the index as the first thing to do. "git status" I think is the
>> recommended way these days ("update-index --refresh" for us old
>> timers) to nondestructively correct the cached stat information
>> discrepancy caused by "cp -R".
>>
>> If you need to resort to "reset --hard", then there is something
>> else going on.
>
> Back than when I had the same problem with git repos on removable file
> systems (if I remember correctly) git status did not correct that
> information. It may be different now.
I do not recall we did anything specific to help removable devices,
so if the report is coming from a filesystem on a removable device
we may be seeing the same symptom.
I somehow doubt that is the case, though.
A not-entirely-inplausible theory is that the index in the original
repository somehow marks modified entries as clean, fooling "status"
that is run in the original repository into reporting that nothing
changed. Because "cp -R" into a different location forces the
content-level checking, "status" run in the copy notices that they
are indeed different and tells the true story. If that is the case,
it would be interesting to see how the index got into that state.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html