{"thread":{"id":"21278","subject":"Potentially dangerous behavior of git gc","startedAt":"2009-10-19T08:04:58Z","lastAt":"2009-10-20T11:40:32Z","messageCount":3,"participants":["Sergio Callegari","Miklos Vajna","Sergio"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"125353","messageId":"loom.20091019T095725-840@post.gmane.org","threadId":"21278","inReplyTo":null,"subject":"Potentially dangerous behavior of git gc","fromName":"Sergio Callegari","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-10-19T08:04:58Z","receivedAt":"2009-10-19T08:04:58Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Hi,\n\nI encountered an issue with git gc.\n\nConsider the following scenario. Repo A is using repo B as an alternate object\ndatabase through the .git/objects/info/alternates mechanism. B is at\n/some_path/B. A has some references, including HEAD that are pointing at\nobjects that are in fact in the object database of B.\n\nFor some reasons, paths are modified on the machine, so that B gets moved at\n/some_new_path/B.\n\nObviously A cannot find its objects anymore and its alternate info should be\nupdated.\n\nSuppose that now one runs git gc on A.\n\nCorrectly git gc complains about the broken alternate link.\nAnd then complains again as it cannot find some objects.\n\nHowever, rather than trying to preserve the repo integrity, it then _removes_\nall the references pointing to non existing objects.\n\nWith this when the alternate info of A is finally updated, A is broken, missing\nmany references and not having a head anymore.\n\nWould it be better to have git gc not to take dangerous actions on potentially\nproblematic repos?\n\nThanks\n\nSergio\n"},{"id":"125371","messageId":"20091019112153.GX6115@genesis.frugalware.org","threadId":"21278","inReplyTo":"loom.20091019T095725-840@post.gmane.org","subject":"Re: Potentially dangerous behavior of git gc","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2009-10-19T11:21:53Z","receivedAt":"2009-10-19T11:21:53Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari wrote:\n> With this when the alternate info of A is finally updated, A is broken, missing\n> many references and not having a head anymore.\n> \n> Would it be better to have git gc not to take dangerous actions on potentially\n> problematic repos?\n\nSuch repos are usually created using git clone -s. See the NOTE of the\nmanpage under the -s option, probably you want to use git repack -a\nafter git clone.\n"},{"id":"125467","messageId":"loom.20091020T132839-911@post.gmane.org","threadId":"21278","inReplyTo":"20091019112153.GX6115@genesis.frugalware.org","subject":"Re: Potentially dangerous behavior of git gc","fromName":"Sergio","fromEmail":"sergio.callegari@gmail.com","sentAt":"2009-10-20T11:40:32Z","receivedAt":"2009-10-20T11:40:32Z","isPatch":false,"sender":{"key":"sergio.callegari@gmail.com","avatar":"https://gravatar.com/avatar/c98f41317e0422c1e630385de0e3970227b8e5ad15f35ba8586066467cc833bc?d=mp&s=160"},"body":"Miklos Vajna frugalware.org> writes:\n\n> \n> On Mon, Oct 19, 2009 at 08:04:58AM +0000, Sergio Callegari\n gmail.com> wrote:\n> > With this when the alternate info of A is finally updated, A is broken, \nmissing\n> > many references and not having a head anymore.\n> > \n> > Would it be better to have git gc not to take dangerous actions on \npotentially\n> > problematic repos?\n> \n> Such repos are usually created using git clone -s. See the NOTE of the\n> manpage under the -s option, probably you want to use git repack -a\n> after git clone.\n> \n\nThanks, unfortunately, that was not really my point. But I now see that I\ncannot create a test case to reproduce my issue. Briefly what happened to\nme is the following\n\n1) Create repo A\n2) Clone with -s A into B\n3) Do some work in B, being happy of maintaining the alternate\n4) At some point, move A elsewhere\n5) Do a couple of things in B, including a git gc, before realizing that\n moving A had created problems to B\n6) Rush to make A reachable by B again by updating the info/alternates\n file in B\n7) Realize that in spite of 6) B is gone... no more ref/heads/master, git\n thinks that this is a new empty repo.\n\nAnd certainly the fault was of some of the \"two things\" done in 5). At the\nbeginning I thought that the blame was of git gc, but I see that I cannot\nreproduce the situation at all with test cases.\n\nSo I will give up for now... I'll get back to it if I ever have a similar\nproblem. Once more, sorry for the noise.\n\nSergio \n"}]}