{"thread":{"id":"16152","subject":"Git SVN Rebranching Issue","startedAt":"2008-11-03T14:07:47Z","lastAt":"2008-11-06T20:48:17Z","messageCount":9,"participants":["Matt Kern","Eric Wong","Dmitry Potapov","Sverre Rabbelier","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"94763","messageId":"20081103140746.GA5969@mars.cyantechnology.local","threadId":"16152","inReplyTo":null,"subject":"Git SVN Rebranching Issue","fromName":"Matt Kern","fromEmail":"matt.kern@undue.org","sentAt":"2008-11-03T14:07:47Z","receivedAt":"2008-11-03T14:07:47Z","isPatch":false,"sender":{"key":"matt.kern@undue.org","avatar":null},"body":"I have a git-svn issue which keeps biting me.\n\nMy company uses svn as its primary version control system. We\nfrequently create branches, e.g. /branches/somebranch, by forking the\ntrunk to ensure stability over the \"somebranch\" code. The problem is\nthat we also frequently blow away /branches/somebranch and refork it\nfrom the trunk.\n\ngit-svn does a good job for most work, but I notice that if you delete\nthe \"somebranch\" branch in svn and then refork it, also in svn, then\nwhen you git-svn fetch, the git commit at the head of remotes/somebranch\nwill have two parents: the first is the previous head of\nremotes/somebranch, and the second is the head of remotes/trunk. Surely\nonly the remotes/trunk parent should be listed? Any connection with the\nprevious remotes/somebranch is an accident of naming. The real problem\nthen comes when you come to look at the history in gitk. If\n\"somebranch\" is rebranched many times, the git history starts looking\npretty complicated, when in fact it should simply be the linear history\nof remotes/trunk up to the branch point followed by a few,\nbranch-specific commits. Is there any way to prevent (or modify) the\ngit history to remove the errant parent?\n\nIn the ideal world, we wouldn't reuse branch names in svn, but it is\nconvenient and doesn't cause problems for svn users. I can't force the\nrest of the company to change to accommodate my use of git...\n\nI am using git (svn) version 1.5.6.5 (svn 1.4.6) from Debian/Lenny and\ncan provide a trivial repository demonstrating the problem if anyone is\ninterested.\n\nMatt\n\n-- \nMatt Kern\nhttp://www.undue.org/\n"},{"id":"94873","messageId":"20081104084111.GB14405@untitled","threadId":"16152","inReplyTo":"20081103140746.GA5969@mars.cyantechnology.local","subject":"Re: Git SVN Rebranching Issue","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-11-04T08:41:11Z","receivedAt":"2008-11-04T08:41:11Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Matt Kern wrote:\n> I have a git-svn issue which keeps biting me.\n> \n> My company uses svn as its primary version control system. We\n> frequently create branches, e.g. /branches/somebranch, by forking the\n> trunk to ensure stability over the \"somebranch\" code. The problem is\n> that we also frequently blow away /branches/somebranch and refork it\n> from the trunk.\n> \n> git-svn does a good job for most work, but I notice that if you delete\n> the \"somebranch\" branch in svn and then refork it, also in svn, then\n> when you git-svn fetch, the git commit at the head of remotes/somebranch\n> will have two parents: the first is the previous head of\n> remotes/somebranch, and the second is the head of remotes/trunk. Surely\n> only the remotes/trunk parent should be listed? Any connection with the\n> previous remotes/somebranch is an accident of naming. The real problem\n> then comes when you come to look at the history in gitk. If\n> \"somebranch\" is rebranched many times, the git history starts looking\n> pretty complicated, when in fact it should simply be the linear history\n> of remotes/trunk up to the branch point followed by a few,\n> branch-specific commits. Is there any way to prevent (or modify) the\n> git history to remove the errant parent?\n\nHi Matt,\n\nShort answer: you can use grafts to remove parents.\n\n\nIt was actually an intentional design decision on my part preserve\nparents based on branch name. We would eventually otherwise lose\nhistory of the now-deleted branches, as reflogs can expire.\n\nTo me, it's easier to drop history connections you don't want with\ngrafts than to recover it by refetching.\n\n-- \nEric Wong\n"},{"id":"94879","messageId":"20081104094224.GC24100@dpotapov.dyndns.org","threadId":"16152","inReplyTo":"20081104084111.GB14405@untitled","subject":"Re: Git SVN Rebranching Issue","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-11-04T09:42:24Z","receivedAt":"2008-11-04T09:42:24Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:\n> \n> Short answer: you can use grafts to remove parents.\n\nUsing grafts requires some cautious, especially when it is used to make\nsome commits unreachable, because git gc can remove unreachable commits.\nAlso, a repository with grafts cannot be cloned. So using grafts looks\nlike more as workaround rather a real solution.\n\n> \n> It was actually an intentional design decision on my part preserve\n> parents based on branch name. We would eventually otherwise lose\n> history of the now-deleted branches, as reflogs can expire.\n\nWould it not be better to save the old branch using \"@SVN-NUMBER\" as\nsuffix? Thus, those do not need the old branch can easily delete it.\n\n\nDmitry\n"},{"id":"94881","messageId":"bd6139dc0811040215r68cc8443y2b723d6018e2a17b@mail.gmail.com","threadId":"16152","inReplyTo":"20081104094224.GC24100@dpotapov.dyndns.org","subject":"Re: Git SVN Rebranching Issue","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-11-04T10:15:53Z","receivedAt":"2008-11-04T10:15:53Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, Nov 4, 2008 at 10:42, Dmitry Potapov wrote:\n> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:\n>> Short answer: you can use grafts to remove parents.\n>\n> Using grafts requires some cautious, especially when it is used to make\n> some commits unreachable, because git gc can remove unreachable commits.\n> Also, a repository with grafts cannot be cloned. So using grafts looks\n> like more as workaround rather a real solution\n\nI think what was meants is to use grafts and then make them permanent\nwith 'git filter-branch'.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"94884","messageId":"20081104112409.GA21758@deimos.cyantechnology.local","threadId":"16152","inReplyTo":"20081104094224.GC24100@dpotapov.dyndns.org","subject":"Re: Git SVN Rebranching Issue","fromName":"Matt Kern","fromEmail":"matt.kern@undue.org","sentAt":"2008-11-04T11:24:10Z","receivedAt":"2008-11-04T11:24:10Z","isPatch":false,"sender":{"key":"matt.kern@undue.org","avatar":null},"body":"> > It was actually an intentional design decision on my part preserve\n> > parents based on branch name. We would eventually otherwise lose\n> > history of the now-deleted branches, as reflogs can expire.\n> \n> Would it not be better to save the old branch using \"@SVN-NUMBER\" as\n> suffix? Thus, those do not need the old branch can easily delete it.\n\nI would second this approach. \n\nOur svn repository isn't particularly big or old, but if someone were to\nmake a branch now, there is a fair chance it will have the same name as\nan old branch but have absolutely nothing to do with that old branch.\nThe situation will only get worse as our svn repository grows and more\nbranches are created/deleted.\n\nMatt\n\n-- \nMatt Kern\nhttp://www.undue.org/\n"},{"id":"94945","messageId":"20081105003318.GA5666@hand.yhbt.net","threadId":"16152","inReplyTo":"20081104094224.GC24100@dpotapov.dyndns.org","subject":"Re: Git SVN Rebranching Issue","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-11-05T00:33:19Z","receivedAt":"2008-11-05T00:33:19Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Dmitry Potapov wrote:\n> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:\n> > \n> > Short answer: you can use grafts to remove parents.\n> \n> Using grafts requires some cautious, especially when it is used to make\n> some commits unreachable, because git gc can remove unreachable commits.\n> Also, a repository with grafts cannot be cloned. So using grafts looks\n> like more as workaround rather a real solution.\n\nI don't think extra history is harmful at all, so the grafts could even\nbe temporary. AFAIK, the extra history is only an aesthetic issue in\nvisualizers (and I actually like to see it myself).\n\nBesides, git svn is just a workaround until the SVN repository is\nreplaced entirely by git :)\n\n> > It was actually an intentional design decision on my part preserve\n> > parents based on branch name. We would eventually otherwise lose\n> > history of the now-deleted branches, as reflogs can expire.\n> \n> Would it not be better to save the old branch using \"@SVN-NUMBER\" as\n> suffix? Thus, those do not need the old branch can easily delete it.\n\nThat would require renaming _existing_ branches to their \"@SVN-NUMBER\"\nname; which would break mechanisms for tracking branches based on\nrefname.\n\n-- \nEric Wong\n"},{"id":"94946","messageId":"32541b130811041640x18e3bbfewa639df356ff7561e@mail.gmail.com","threadId":"16152","inReplyTo":"20081105003318.GA5666@hand.yhbt.net","subject":"Re: Git SVN Rebranching Issue","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-05T00:40:39Z","receivedAt":"2008-11-05T00:40:39Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong wrote:\n> Dmitry Potapov wrote:\n>> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:\n>> >\n>> > Short answer: you can use grafts to remove parents.\n>>\n>> Using grafts requires some cautious, especially when it is used to make\n>> some commits unreachable, because git gc can remove unreachable commits.\n>> Also, a repository with grafts cannot be cloned. So using grafts looks\n>> like more as workaround rather a real solution.\n>\n> I don't think extra history is harmful at all, so the grafts could even\n> be temporary. AFAIK, the extra history is only an aesthetic issue in\n> visualizers (and I actually like to see it myself).\n\nBut it's *lying* history in this case; it doesn't reflect what really\nhappened in svn *or* in real life. I'd say lying history is most\noften harmful. \"git blame\" and \"git log\" will lie in this case, for\nexample.\n\n>> Would it not be better to save the old branch using \"@SVN-NUMBER\" as\n>> suffix? Thus, those do not need the old branch can easily delete it.\n>\n> That would require renaming _existing_ branches to their \"@SVN-NUMBER\"\n> name; which would break mechanisms for tracking branches based on\n> refname.\n\nWell, you wouldn't have to rename the existing branch. You would\nsimply create the new @SVN-NUMBER branch when it became clear that\nthat commit is no longer reachable from the undecorated branch ref.\nIsn't that why the @SVN-NUMBER branches are needed in the first place?\n\nAs for tracking branches based on refname, it seems like the current\nbehaviour of pretending to merge histories together wouldn't work too\nwell anyway. For someone pulling from the messed-up branch, they\nreally *will* need to rewind and re-pull, since that's exactly what\nhappened in svn. I don't think git has any chance of doing this\nautomatically just because of a new commit with two parents.\n\nDisclaimer: I haven't run into any of this myself since I don't\nrecycle branch names in svn :)\n\nHave fun,\n\nAvery\n"},{"id":"95035","messageId":"20081106093917.GA15686@untitled","threadId":"16152","inReplyTo":"32541b130811041640x18e3bbfewa639df356ff7561e@mail.gmail.com","subject":"Re: Git SVN Rebranching Issue","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-11-06T09:39:17Z","receivedAt":"2008-11-06T09:39:17Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Avery Pennarun wrote:\n> On Tue, Nov 4, 2008 at 7:33 PM, Eric Wong wrote:\n> > Dmitry Potapov wrote:\n> >> On Tue, Nov 04, 2008 at 12:41:11AM -0800, Eric Wong wrote:\n> >> >\n> >> > Short answer: you can use grafts to remove parents.\n> >>\n> >> Using grafts requires some cautious, especially when it is used to make\n> >> some commits unreachable, because git gc can remove unreachable commits.\n> >> Also, a repository with grafts cannot be cloned. So using grafts looks\n> >> like more as workaround rather a real solution.\n> >\n> > I don't think extra history is harmful at all, so the grafts could even\n> > be temporary. AFAIK, the extra history is only an aesthetic issue in\n> > visualizers (and I actually like to see it myself).\n> \n> But it's *lying* history in this case; it doesn't reflect what really\n> happened in svn *or* in real life. I'd say lying history is most\n> often harmful. \"git blame\" and \"git log\" will lie in this case, for\n> example.\n\nMaybe, but I don't find having a choice to follow _either_:\n a) copy history (the REAL history)\n b) the name history (faked)\n\nI've had to deal with repositories that recycled branch names for a\nwhile now and it hasn't been an issue for me nor anybody else\nusing git svn on them.\n\ngit log --first-parent exists for following copy history, too.\n\n> >> Would it not be better to save the old branch using \"@SVN-NUMBER\" as\n> >> suffix? Thus, those do not need the old branch can easily delete it.\n> >\n> > That would require renaming _existing_ branches to their \"@SVN-NUMBER\"\n> > name; which would break mechanisms for tracking branches based on\n> > refname.\n> \n> Well, you wouldn't have to rename the existing branch. You would\n> simply create the new @SVN-NUMBER branch when it became clear that\n> that commit is no longer reachable from the undecorated branch ref.\n> Isn't that why the @SVN-NUMBER branches are needed in the first place?\n\nMaking @SVN-NUMBER branches for new/latest branches is even more\nconfusing. That would mean the user would have to remember the\n@SVN-NUMBER every time they wanted to do operations with the\nrecycled branch.\n\nThe current use of @SVN-NUMBER in branches are only used when following\nparents (when repositories are rearranged). In retrospect, it's\nprobably possible to for git-svn to not make them user-visible (I seem\nto recall they made development/debugging/testing easier in the past,\nthough).\n\n> As for tracking branches based on refname, it seems like the current\n> behaviour of pretending to merge histories together wouldn't work too\n> well anyway. For someone pulling from the messed-up branch, they\n> really *will* need to rewind and re-pull, since that's exactly what\n> happened in svn. I don't think git has any chance of doing this\n> automatically just because of a new commit with two parents.\n\n\"git svn rebase\" and \"git log ..$RECYCLED\" both work. non-FF/non-squash\npulls won't, of course.\n\n> Disclaimer: I haven't run into any of this myself since I don't\n> recycle branch names in svn :)\n\nLucky you :)\n\n-- \nEric Wong\n"},{"id":"95078","messageId":"32541b130811061248n151c7512w4f6ba140ebb283af@mail.gmail.com","threadId":"16152","inReplyTo":"20081106093917.GA15686@untitled","subject":"Re: Git SVN Rebranching Issue","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2008-11-06T20:48:17Z","receivedAt":"2008-11-06T20:48:17Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Thu, Nov 6, 2008 at 4:39 AM, Eric Wong wrote:\n> Avery Pennarun wrote:\n>> Well, you wouldn't have to rename the existing branch. You would\n>> simply create the new @SVN-NUMBER branch when it became clear that\n>> that commit is no longer reachable from the undecorated branch ref.\n>> Isn't that why the @SVN-NUMBER branches are needed in the first place?\n>\n> Making @SVN-NUMBER branches for new/latest branches is even more\n> confusing. That would mean the user would have to remember the\n> @SVN-NUMBER every time they wanted to do operations with the\n> recycled branch.\n\nHmm, I wasn't suggesting using @SVN-NUMBER for the *latest* branches;\nyou create one for the older branches at the time the old one is\nreplaced by the new one.\n\nNote that this is exactly how it works in svn, so in fact it's a very\nclean mapping from svn onto git. If I ask about\n/branches/whatever/myfile.c@SVN-NUMBER, it's different from asking\nabout \"-r SVN-NUMBER /branches/whatever/myfile.c\". The difference is\nprecisely what we're talking about representing here.\n\nWhat's important is that they really are two totally unrelated\nbranches of history, which happen to have been referred to by the same\nname at the time when they were current.\n\n> The current use of @SVN-NUMBER in branches are only used when following\n> parents (when repositories are rearranged). In retrospect, it's\n> probably possible to for git-svn to not make them user-visible (I seem\n> to recall they made development/debugging/testing easier in the past,\n> though).\n\nI wouldn't want to lose those names as they are now; they're\ninconvenient, but important, because they accurately represent the\nimportant points in svn history as it has been imported.\n\nHave fun,\n\nAvery\n"}]}