{"thread":{"id":"19088","subject":"git 1.5.4.3 push incorrectly honors grafts file","startedAt":"2009-04-27T15:51:05Z","lastAt":"2009-05-05T01:00:20Z","messageCount":7,"participants":["elupus","Michael J Gruber","Johannes Sixt","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"112431","messageId":"d5uvsf40ln1i.fbvskgg1w9e6$.dlg@40tude.net","threadId":"19088","inReplyTo":null,"subject":"git 1.5.4.3 push incorrectly honors grafts file","fromName":"elupus","fromEmail":"elupus@ecce.se","sentAt":"2009-04-27T15:51:05Z","receivedAt":"2009-04-27T15:51:05Z","isPatch":false,"sender":{"key":"elupus@ecce.se","avatar":null},"body":"Hi, \n\nI recently had a problem with git push honoring the grafts file. It caused\nit not to push all data required for a branch to the remote repository,\nrendering it impossible to clone the remote repository (missing blobs)\n\nThis was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).\n\nHas this issue been fixed in later git version? I saw a thread talking\nabout it a long time ago (long before my release in question) on this\nmailing list, but nothing was mentioned about if it was actually solved.\n\nRegards\nJoakim Plate\n"},{"id":"112922","messageId":"atsddmx5kuva.1fyy780hhh9t2$.dlg@40tude.net","threadId":"19088","inReplyTo":"d5uvsf40ln1i.fbvskgg1w9e6$.dlg@40tude.net","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"elupus","fromEmail":"elupus@ecce.se","sentAt":"2009-05-03T17:14:22Z","receivedAt":"2009-05-03T17:14:22Z","isPatch":false,"sender":{"key":"elupus@ecce.se","avatar":null},"body":"On Mon, 27 Apr 2009 17:51:05 +0200, elupus wrote:\n\n> Hi, \n> \n> I recently had a problem with git push honoring the grafts file. It caused\n> it not to push all data required for a branch to the remote repository,\n> rendering it impossible to clone the remote repository (missing blobs)\n> \n> This was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).\n> \n> Has this issue been fixed in later git version? I saw a thread talking\n> about it a long time ago (long before my release in question) on this\n> mailing list, but nothing was mentioned about if it was actually solved.\n> \n> Regards\n> Joakim Plate\n\nBump, anybody know of a way to avoid this? The problem even occurs on the\nlocal machine in that git gc will cleanup stuff that isn't required due to\nthe grafts file, rendering the repo invalid if the graft file is removed.\n\nI don't think running filter-branch on the git svn imported branches seems\nlike a good idea. since that would also wreak havoc on any repo that pulls\nfrom mine (ie still private repo like usb stick or other dev machine). \n\nImho, grafts shouldn't be honored on either push/pull/gc operations. \n\nJoakim\n"},{"id":"112970","messageId":"49FEE0A6.3060905@drmicha.warpmail.net","threadId":"19088","inReplyTo":"d5uvsf40ln1i.fbvskgg1w9e6$.dlg@40tude.net","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-05-04T12:33:42Z","receivedAt":"2009-05-04T12:33:42Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"elupus venit, vidit, dixit 27.04.2009 17:51:\n> Hi, \n> \n> I recently had a problem with git push honoring the grafts file. It caused\n> it not to push all data required for a branch to the remote repository,\n> rendering it impossible to clone the remote repository (missing blobs)\n> \n> This was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).\n> \n> Has this issue been fixed in later git version? I saw a thread talking\n\nHow about testing this yourself, since you have a test case in your\nhands and only need to build a more current git? Alternatively,\nproviding a simple test script would allow others to test this for you.\n\nCheers,\nMichael\n\n> about it a long time ago (long before my release in question) on this\n> mailing list, but nothing was mentioned about if it was actually solved.\n> \n> Regards\n> Joakim Plate\n> \n"},{"id":"112994","messageId":"49FF2507.6070602@kdbg.org","threadId":"19088","inReplyTo":"atsddmx5kuva.1fyy780hhh9t2$.dlg@40tude.net","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-05-04T17:25:27Z","receivedAt":"2009-05-04T17:25:27Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"elupus schrieb:\n> On Mon, 27 Apr 2009 17:51:05 +0200, elupus wrote:\n> \n>> Hi, \n>>\n>> I recently had a problem with git push honoring the grafts file. It caused\n>> it not to push all data required for a branch to the remote repository,\n>> rendering it impossible to clone the remote repository (missing blobs)\n>>\n>> This was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).\n>>\n>> Has this issue been fixed in later git version? I saw a thread talking\n>> about it a long time ago (long before my release in question) on this\n>> mailing list, but nothing was mentioned about if it was actually solved.\n>>\n>> Regards\n>> Joakim Plate\n> \n> Bump, anybody know of a way to avoid this? The problem even occurs on the\n> local machine in that git gc will cleanup stuff that isn't required due to\n> the grafts file, rendering the repo invalid if the graft file is removed.\n> \n> I don't think running filter-branch on the git svn imported branches seems\n> like a good idea. since that would also wreak havoc on any repo that pulls\n> from mine (ie still private repo like usb stick or other dev machine). \n> \n> Imho, grafts shouldn't be honored on either push/pull/gc operations. \n\nRight.\n\nIt's a know issue. But it was nobody's itch, yet, perhaps because too few \npeople use grafts. There is a topic, cc/replace, in Junio's pu branch that \nintroduces \"replacement objects\"; these are a generalization of grafts. If \neffort is invested, then it's best to nurse this topic.\n\n-- Hannes\n"},{"id":"112996","messageId":"yj2z78echiy8$.1mp64tzd3njkz.dlg@40tude.net","threadId":"19088","inReplyTo":"49FF2507.6070602@kdbg.org","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"elupus","fromEmail":"elupus@ecce.se","sentAt":"2009-05-04T17:54:25Z","receivedAt":"2009-05-04T17:54:25Z","isPatch":false,"sender":{"key":"elupus@ecce.se","avatar":null},"body":"On Mon, 04 May 2009 19:25:27 +0200, Johannes Sixt wrote:\n\n> elupus schrieb:\n>> [26 quoted lines suppressed]\n> \n> Right.\n> \n> It's a know issue. But it was nobody's itch, yet, perhaps because too few \n> people use grafts. There is a topic, cc/replace, in Junio's pu branch that \n> introduces \"replacement objects\"; these are a generalization of grafts. If \n> effort is invested, then it's best to nurse this topic.\n> \n> -- Hannes\n\nAh okey. Atleast then i know to thread carfully. \n\nThe ugglies thing about this was that git gc had actually pruned a commit\nfrom my repo due to an invalid graft's file. That push/pull didn't work\nwasn't soo bad, but that my repo got corrupted due to an invalid graft file\nis abit scary. \n\nLuckily in my case it was a git svn repo, and I even think i found a way to\njust rebuild that branch where it occured.\n\nIt's quite probable that the problem's I had with the push/pull was due to\nthis missing commit. Since all my grafts (part from the wrong one) are only\nadditions of parents to commits. A cloned repo should still be okey even if\nit does honor the grafts file (i think without knowning too much about the\ninards of git).\n\nJoakim\n"},{"id":"113004","messageId":"20090504204022.GE4863@dpotapov.dyndns.org","threadId":"19088","inReplyTo":"atsddmx5kuva.1fyy780hhh9t2$.dlg@40tude.net","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-05-04T20:40:22Z","receivedAt":"2009-05-04T20:40:22Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, May 03, 2009 at 07:14:22PM +0200, elupus wrote:\n> On Mon, 27 Apr 2009 17:51:05 +0200, elupus wrote:\n> \n> > Hi, \n> > \n> > I recently had a problem with git push honoring the grafts file. It caused\n> > it not to push all data required for a branch to the remote repository,\n> > rendering it impossible to clone the remote repository (missing blobs)\n> > \n> > This was with an not so fresh git version of 1.5.4.3 (ubuntu hardy).\n> > \n> > Has this issue been fixed in later git version? I saw a thread talking\n> > about it a long time ago (long before my release in question) on this\n> > mailing list, but nothing was mentioned about if it was actually solved.\n> > \n> > Regards\n> > Joakim Plate\n> \n> Bump, anybody know of a way to avoid this?\n\nDon't use the grafts file. It is primary useful immediately after importing\nsome repository to Git when you need to clean up it a bit before fixing the\nresult by running git-filter-branch. Another usage of it is to add old history,\nwhich is not part of the official repository. In the last case, you only add\na new parent, so it should not be a problem, except this addition is purely\nlocal and any cloned repo will not have it.\n\n> The problem even occurs on the\n> local machine in that git gc will cleanup stuff that isn't required due to\n> the grafts file, rendering the repo invalid if the graft file is removed.\n\nIt may happen only if your graft makes some part of history unreachable. And\nas I said above, using the grafts file should be avoided wherever possible,\nand graft that replaces or removes some parents should only be used if you\nare going to run git-filter-branch after that.\n\n> \n> I don't think running filter-branch on the git svn imported branches seems\n> like a good idea. since that would also wreak havoc on any repo that pulls\n> from mine (ie still private repo like usb stick or other dev machine).\n\nIf you migrate from SVN to Git and want to edit history after importing, you\nshould run filter-branch before making this repository public.  Re-writing\npublic history is always a bad idea, regardless how it is done. If you use\ngit-svn for bidirectional synchronization then you most like use grafts in\nthe way it was not intended to use...\n\n> Imho, grafts shouldn't be honored on either push/pull/gc operations.\n\nIf git gc will not honor grafts then it may delete those that are referred\nby grafts, which is clearly wrong. So, perhaps, what you really want is that\ngit-gc should consider grafts as an additional source of information rather\nthan replacement. (Actually, git-gc is high level wrapper over git-repack,\ngit-prune, etc, which should be changed.) Also, git-fsck needs to be changed\nto consider grafts as an additional source of information...\n\nWhether grafts should be completely ignored by push/pull is not completely\nclear. Though it may be the best course of action, it is also confusing,\nbecause git log and other commands show you one history, but something\ndifferent gets pulled or pushed. (So, anyone who inherited such a repo from\nanother co-worker is bound to a big surprise as to why pull/push do not\nwork correctly). Also, we have a single logic that creates packages, whether\nit is packages for network transfer or local storage, but it should be\nchanged to work different based on whether it is local or non-local package.\nSo, it appears to me a lot of changes, but the end result will be still not\nsomething what you really want to use for reliable storage...\n\nIMHO, grafts should not be used at all except very rare cases like editing\nan imported history before making it public.\n\n\nDmitry\n"},{"id":"113019","messageId":"1tckgcdml91fv$.asxg8bv2cluc$.dlg@40tude.net","threadId":"19088","inReplyTo":"20090504204022.GE4863@dpotapov.dyndns.org","subject":"Re: git 1.5.4.3 push incorrectly honors grafts file","fromName":"elupus","fromEmail":"elupus@ecce.se","sentAt":"2009-05-05T01:00:20Z","receivedAt":"2009-05-05T01:00:20Z","isPatch":false,"sender":{"key":"elupus@ecce.se","avatar":null},"body":"On Tue, 5 May 2009 00:40:22 +0400, Dmitry Potapov wrote:\n\n> \n> It may happen only if your graft makes some part of history unreachable. And\n> as I said above, using the grafts file should be avoided wherever possible,\n> and graft that replaces or removes some parents should only be used if you\n> are going to run git-filter-branch after that.\n\nUnderstandable, but not really an option in my case. (see below)\n\n> If you migrate from SVN to Git and want to edit history after importing, you\n> should run filter-branch before making this repository public.  Re-writing\n> public history is always a bad idea, regardless how it is done. If you use\n> git-svn for bidirectional synchronization then you most like use grafts in\n> the way it was not intended to use...\n\nIn my case i'm not migrating. I'm following a svn repo, but want to do my\nown development in git.\n\n> If git gc will not honor grafts then it may delete those that are referred\n> by grafts, which is clearly wrong. So, perhaps, what you really want is that\n> git-gc should consider grafts as an additional source of information rather\n> than replacement. (Actually, git-gc is high level wrapper over git-repack,\n> git-prune, etc, which should be changed.) Also, git-fsck needs to be changed\n> to consider grafts as an additional source of information...\n\nYea, sounds like the correct approach.\n\n> IMHO, grafts should not be used at all except very rare cases like editing\n> an imported history before making it public.\n\nSuppose so, but they are also very usefull for git svn repo's where they\ncan be used to correct for merge history. For example a feature branch\ngetting resynced to the trunk multiple times during it's lifetime. Adding\ngrafts for atleast the latest such occurance, makes it way easier to git\ndiff / git merge --squash and so on between the branches.\n\nAlso after the branch have been merged back into trunk, there could be a\npoint to add a graft as the previous branch will likely be deleted from the\nsvn repo, and thus would end up unreachable in the git repo should one\ndecide to remove the ref to the tip since there is not branch tracking in\nthe git svn client.\n\nIn a perfect world (not a likely one as i'll not spend time on implementing\nit) I would like to be able to add new parents to commits and have them\nbecome permanent through something like filter-branch, without this ruining\nanything for anybody that pulls from this repo.\n\nJoakim\n"}]}