Re: git repository modified after migration

Michael J Gruber [off-list ref] 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.

Junio C Hamano venit, vidit, dixit 11.01.2016 19:19:

Michael J Gruber [off-list ref] writes:

quoted

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.

Michael