{"thread":{"id":"41075","subject":"git repository modified after migration","startedAt":"2015-12-25T20:49:40Z","lastAt":"2016-01-12T18:07:29Z","messageCount":6,"participants":["Yang Yu","Michael J Gruber","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"275002","messageId":"CAFwKRnQ_EZ73DBfrb0HNks3dt3=YJbLRoHvB0mfsD9FA-ey6hA@mail.gmail.com","threadId":"41075","inReplyTo":null,"subject":"git repository modified after migration","fromName":"Yang Yu","fromEmail":"yang.yu.list@gmail.com","sentAt":"2015-12-25T20:49:40Z","receivedAt":"2015-12-25T20:49:40Z","isPatch":false,"sender":{"key":"yang.yu.list@gmail.com","avatar":null},"body":"I migrated a 11G git repository converted from svn on a host with\nDebian 8.2, reiserfs, git 2.1.4 to a host with Ubuntu 12.04.5 LTS,\nxfs, git 2.6.4. After the migration, `git status` showing a good\namount of files modified.\n\nI did the transfer with\n1) `rsync -azP`, after noticing the modified files I ran `rsync -avH\n--delete` but it did not correct the problem\n2) tar zcf, then on the destination download the tar.gz (served by\nnginx) with wget\n\nBoth had the same result. But the original repository was still clean.\n\nI did some comparison between \"modified\" and original files\na) same hash (md5sum, shasum)\nb) same permission (-rw-r--r-- 1 )\nc) same encoding and line termination (UTF-8 Unicode (with BOM) text,\nwith CRLF line terminators)\nd) no git attributes for either\n\n\nOn the destination host, I ran `git checkout` on each of those\nmodified files. After one pass I got less modified files. Repeating\n`git checkout` on remaining files for a few more times, finally I got\na clean repository on the destination host.\n\nWhat could have caused git to consider those files as modified? And\nwhy multiple `git checkout` again the same file was necessary?\n\nThanks.\n\n\nYang\n"},{"id":"275646","messageId":"5693C48A.7060801@drmicha.warpmail.net","threadId":"41075","inReplyTo":"CAFwKRnQ_EZ73DBfrb0HNks3dt3=YJbLRoHvB0mfsD9FA-ey6hA@mail.gmail.com","subject":"Re: git repository modified after migration","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-01-11T15:04:42Z","receivedAt":"2016-01-11T15:04:42Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Yang Yu venit, vidit, dixit 25.12.2015 21:49:\n> I migrated a 11G git repository converted from svn on a host with\n> Debian 8.2, reiserfs, git 2.1.4 to a host with Ubuntu 12.04.5 LTS,\n> xfs, git 2.6.4. After the migration, `git status` showing a good\n> amount of files modified.\n> \n> I did the transfer with\n> 1) `rsync -azP`, after noticing the modified files I ran `rsync -avH\n> --delete` but it did not correct the problem\n> 2) tar zcf, then on the destination download the tar.gz (served by\n> nginx) with wget\n> \n> Both had the same result. But the original repository was still clean.\n> \n> I did some comparison between \"modified\" and original files\n> a) same hash (md5sum, shasum)\n> b) same permission (-rw-r--r-- 1 )\n> c) same encoding and line termination (UTF-8 Unicode (with BOM) text,\n> with CRLF line terminators)\n> d) no git attributes for either\n> \n> \n> On the destination host, I ran `git checkout` on each of those\n> modified files. After one pass I got less modified files. Repeating\n> `git checkout` on remaining files for a few more times, finally I got\n> a clean repository on the destination host.\n> \n> What could have caused git to consider those files as modified? And\n> why multiple `git checkout` again the same file was necessary?\n> \n> Thanks.\n> \n> \n> Yang\n\nThis happens whenever the \"stat\" information changes, e.g. due to\nchanged device numbering and such. \"git reset --hard\" would have been\nthe quickiest way to reset the stat cache/index - after git diff, of\ncourse ;)\n\nMichael\n"},{"id":"275674","messageId":"CAFwKRnRV7dx49+dku13b--W2g9t=OJiyuT2O_dv4ZZ3PdD1v3g@mail.gmail.com","threadId":"41075","inReplyTo":"5693C48A.7060801@drmicha.warpmail.net","subject":"Re: git repository modified after migration","fromName":"Yang Yu","fromEmail":"yang.yu.list@gmail.com","sentAt":"2016-01-11T17:48:46Z","receivedAt":"2016-01-11T17:48:46Z","isPatch":false,"sender":{"key":"yang.yu.list@gmail.com","avatar":null},"body":"On Mon, Jan 11, 2016 at 9:04 AM, Michael J Gruber\n wrote:\n> This happens whenever the \"stat\" information changes, e.g. due to\n> changed device numbering and such. \"git reset --hard\" would have been\n> the quickiest way to reset the stat cache/index - after git diff, of\n> course ;)\n>\n\n\nCan you go into a bit more details about this? Why does it only affect\ncertain files (always these filed modified) on every host I tried?\nThanks.\n"},{"id":"275678","messageId":"xmqq4mekx9ld.fsf@gitster.mtv.corp.google.com","threadId":"41075","inReplyTo":"5693C48A.7060801@drmicha.warpmail.net","subject":"Re: git repository modified after migration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-11T18:19:26Z","receivedAt":"2016-01-11T18:19:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> This happens whenever the \"stat\" information changes, e.g. due to\n> changed device numbering and such. \"git reset --hard\" would have been\n> the quickiest way to reset the stat cache/index - after git diff, of\n> course ;)\n\nThat does not quite explain why 'git status' reported modified files\nin the first place. It would have refreshed the cached stat info in\nthe index as the first thing to do. \"git status\" I think is the\nrecommended way these days (\"update-index --refresh\" for us old\ntimers) to nondestructively correct the cached stat information\ndiscrepancy caused by \"cp -R\".\n\nIf you need to resort to \"reset --hard\", then there is something\nelse going on.\n"},{"id":"275759","messageId":"5694A4E6.6020508@drmicha.warpmail.net","threadId":"41075","inReplyTo":"xmqq4mekx9ld.fsf@gitster.mtv.corp.google.com","subject":"Re: git repository modified after migration","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-01-12T07:01:58Z","receivedAt":"2016-01-12T07:01:58Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 11.01.2016 19:19:\n> Michael J Gruber writes:\n> \n>> This happens whenever the \"stat\" information changes, e.g. due to\n>> changed device numbering and such. \"git reset --hard\" would have been\n>> the quickiest way to reset the stat cache/index - after git diff, of\n>> course ;)\n> \n> That does not quite explain why 'git status' reported modified files\n> in the first place. It would have refreshed the cached stat info in\n> the index as the first thing to do. \"git status\" I think is the\n> recommended way these days (\"update-index --refresh\" for us old\n> timers) to nondestructively correct the cached stat information\n> discrepancy caused by \"cp -R\".\n> \n> If you need to resort to \"reset --hard\", then there is something\n> else going on.\n\nBack than when I had the same problem with git repos on removable file\nsystems (if I remember correctly) git status did not correct that\ninformation. It may be different now.\n\nMichael\n"},{"id":"275818","messageId":"xmqq8u3uvfha.fsf@gitster.mtv.corp.google.com","threadId":"41075","inReplyTo":"5694A4E6.6020508@drmicha.warpmail.net","subject":"Re: git repository modified after migration","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-12T18:07:29Z","receivedAt":"2016-01-12T18:07:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> Junio C Hamano venit, vidit, dixit 11.01.2016 19:19:\n>> Michael J Gruber writes:\n>> \n>>> This happens whenever the \"stat\" information changes, e.g. due to\n>>> changed device numbering and such. \"git reset --hard\" would have been\n>>> the quickiest way to reset the stat cache/index - after git diff, of\n>>> course ;)\n>> \n>> That does not quite explain why 'git status' reported modified files\n>> in the first place. It would have refreshed the cached stat info in\n>> the index as the first thing to do. \"git status\" I think is the\n>> recommended way these days (\"update-index --refresh\" for us old\n>> timers) to nondestructively correct the cached stat information\n>> discrepancy caused by \"cp -R\".\n>> \n>> If you need to resort to \"reset --hard\", then there is something\n>> else going on.\n>\n> Back than when I had the same problem with git repos on removable file\n> systems (if I remember correctly) git status did not correct that\n> information. It may be different now.\n\nI do not recall we did anything specific to help removable devices,\nso if the report is coming from a filesystem on a removable device\nwe may be seeing the same symptom.\n\nI somehow doubt that is the case, though.\n\nA not-entirely-inplausible theory is that the index in the original\nrepository somehow marks modified entries as clean, fooling \"status\"\nthat is run in the original repository into reporting that nothing\nchanged. Because \"cp -R\" into a different location forces the\ncontent-level checking, \"status\" run in the copy notices that they\nare indeed different and tells the true story. If that is the case,\nit would be interesting to see how the index got into that state.\n"}]}