{"thread":{"id":"9431","subject":"git-svn: Finding the svn-URL of the current branch in git","startedAt":"2007-08-07T18:29:23Z","lastAt":"2007-08-18T21:18:25Z","messageCount":15,"participants":["Matthias Kleine","Peter Baumann","Junio C Hamano","Eric Wong","David Kastrup","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"50142","messageId":"46B8BA03.1030809@gmx.de","threadId":"9431","inReplyTo":null,"subject":"git-svn: Finding the svn-URL of the current branch in git","fromName":"Matthias Kleine","fromEmail":"matthias_kleine@gmx.de","sentAt":"2007-08-07T18:29:23Z","receivedAt":"2007-08-07T18:29:23Z","isPatch":false,"sender":{"key":"matthias_kleine@gmx.de","avatar":null},"body":"Hi there,\n\nwhen running \"git-svn dcommit\" git-svn tries to find the svn-URL of the \ncurrent branch int git by looking for the most recent git log-entry \ncorresponding to a commit in svn (see working_head_info in git-svn). In \ncase a merge just happended this might be the URL of another branch. \nWould using \"log --first-parent\" instead of a plain \"log\" take care of \nthis problem or would it have other undesirable consequences?\n\nRegards,\nMatthias Kleine\n"},{"id":"50145","messageId":"20070807205543.GB27703@xp.machine.xx","threadId":"9431","inReplyTo":"46B8BA03.1030809@gmx.de","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-08-07T20:55:44Z","receivedAt":"2007-08-07T20:55:44Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:\n> Hi there,\n>\n> when running \"git-svn dcommit\" git-svn tries to find the svn-URL of the \n> current branch int git by looking for the most recent git log-entry \n> corresponding to a commit in svn (see working_head_info in git-svn). In \n> case a merge just happended this might be the URL of another branch. Would \n> using \"log --first-parent\" instead of a plain \"log\" take care of this \n> problem or would it have other undesirable consequences?\n>\n\nI had this situation, too.\n\n\n\t\t\ta = svn branch 'a'\n\tm\t\tb = svn branch 'b' (in my case, it was trunk)\n / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n a b\n\nSo trying to dcommit m, git svn can't figure out on which branch, as 'a'\nand 'b' are both reachable. I had to use a graft file to lose one of the\nparents, which let git-svn commit to SVN.\n\nSo for a short fix to get the work done, you could create a graft file\nwhere you fake m to only have one parent.\n\nOn the longer run, I would make sense to have an option to explicitly\nspecify on which SVN branch 'git-svn dcommit' should operate.\n\n-Peter\n"},{"id":"50179","messageId":"f9c0d1$7md$1@sea.gmane.org","threadId":"9431","inReplyTo":"20070807205543.GB27703@xp.machine.xx","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Matthias Kleine","fromEmail":"matthias_kleine@gmx.de","sentAt":"2007-08-08T08:54:55Z","receivedAt":"2007-08-08T08:54:55Z","isPatch":false,"sender":{"key":"matthias_kleine@gmx.de","avatar":null},"body":"Peter Baumann wrote:\n> \n> I had this situation, too.\n> \n> \n> \t\t\ta = svn branch 'a'\n> \t m\t\tb = svn branch 'b' (in my case, it was trunk)\n> / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n> a b\n> \n> So trying to dcommit m, git svn can't figure out on which branch, as 'a'\n> and 'b' are both reachable. I had to use a graft file to lose one of the\n> parents, which let git-svn commit to SVN.\n\nYou're right, both 'a' and 'b' are reachable from 'm'. But if I got it \nright 'm' also contains information as to which one is the first parent \nand thereby which branch we're on. So wouldn't it be enough, if git-svn \nautomatically chose the first parent (using log --first-parent)?\n\n> \n> So for a short fix to get the work done, you could create a graft file\n> where you fake m to only have one parent.\n>\nThanks for that one. I didn't know about the grafts file before.\n\nMatthias\n"},{"id":"50180","messageId":"7vy7gm4cdv.fsf@assigned-by-dhcp.cox.net","threadId":"9431","inReplyTo":"f9c0d1$7md$1@sea.gmane.org","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-08T09:13:48Z","receivedAt":"2007-08-08T09:13:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Kleine writes:\n\n> Peter Baumann wrote:\n>>\n>> I had this situation, too.\n>>\n>>\n>> \t\t\ta = svn branch 'a'\n>> \t m\t\tb = svn branch 'b' (in my case, it was trunk)\n>> / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n>> a b\n>>\n>> So trying to dcommit m, git svn can't figure out on which branch, as 'a'\n>> and 'b' are both reachable. I had to use a graft file to lose one of the\n>> parents, which let git-svn commit to SVN.\n>\n> You're right, both 'a' and 'b' are reachable from 'm'. But if I got\n> it right 'm' also contains information as to which one is the first\n> parent and thereby which branch we're on. So wouldn't it be enough, if\n> git-svn automatically chose the first parent (using log\n> --first-parent)?\n\nParents' order and which branch you are on may not have anything\nto do with each other. Somebody else may have pulled a while on\nb, and you might have pulled from him the merge he created by\ndoing so while you are on branch a.\n"},{"id":"50206","messageId":"f9d3ce$1lo$1@sea.gmane.org","threadId":"9431","inReplyTo":"7vy7gm4cdv.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Matthias Kleine","fromEmail":"matthias_kleine@gmx.de","sentAt":"2007-08-08T18:51:55Z","receivedAt":"2007-08-08T18:51:55Z","isPatch":false,"sender":{"key":"matthias_kleine@gmx.de","avatar":null},"body":"Junio C Hamano wrote:\n> Parents' order and which branch you are on may not have anything\n> to do with each other. Somebody else may have pulled a while on\n> b, and you might have pulled from him the merge he created by\n> doing so while you are on branch a.\n> \n\nYou're right, I didn't think of that. While pondering this I came up \nwith another problem: git-svn currently remembers which svn-branch a \ncommit belongs to by including this information in the git commit log \nmessage.\nThis way it is not possible to have one git-commit appear in more than \none svn branch. Maybe it's better to store this git-commit->svn-branch \nmapping somewhere else. Although it's probably even better to completely \nswitch to git :)\n\nMatthias\n"},{"id":"50210","messageId":"20070808192537.GB27470@xp.machine.xx","threadId":"9431","inReplyTo":"f9d3ce$1lo$1@sea.gmane.org","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-08-08T19:25:37Z","receivedAt":"2007-08-08T19:25:37Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:\n> Junio C Hamano wrote:\n>> Parents' order and which branch you are on may not have anything\n>> to do with each other. Somebody else may have pulled a while on\n>> b, and you might have pulled from him the merge he created by\n>> doing so while you are on branch a.\n>\n> You're right, I didn't think of that. While pondering this I came up with\n> another problem: git-svn currently remembers which svn-branch a commit\n> belongs to by including this information in the git commit log message.\n\nThats true.\n\n> This way it is not possible to have one git-commit appear in more than one\n> svn branch.\n\nBut there is no way that a git commit could appear on several branches\nin SVN, because SVN doesn't have the concept of multiple parents. So you\ncan't have a commit which describes a merge of two branches, because SVN\ncan't store the 2 parents. But you could have 2 commits which describe\nthe same state (e.g. same root tree), but are on seperate branches.\n\nt:= commits on trunk\nb:= commits on branch 'b'\n\nrepo1:\n\tt <-trunk\n\t|\n\tt\n\t| \\\n\tt b <- branch\n\t| /\n\tt\n\nBut this graph is only local to the committers repo. Another person\nusing git-svn to track the SVN repo sees this\n\nrepo2/SVN repo:\n\n\tt <-trunk\n\t|\n\tt\n\t|\n\tt b <- branch\n\t| /\n\tt\n\nSo if you do a 'git merge trunk' in repo1 on branch 'branch', git-svn\nshould produce something like this:\n\nrepo2/SVN repo:\n\ntrunk->\tt t' <- branch\n\t| |\n\tt t'\n\t| |\n\tt b\n\t| /\n\tt\n\nThe interesting case is what it will produce in *YOUR* repo. There are 2\npossibilities:\n\nrepo1 (I):\t\t\t\trepo1 (II)\n\ttb <-trunk <-branch\t\ttrunk->\tt b <- branch\n\t|\t\t\t\t\t| |\n\ttb\t\t\t\t\tt b\n\t| \\\t\t\t\t\t| \\|\n\tt b <- branch\t\t\t\tt b\n\t| /\t\t\t\t\t| /\n\tt\t\t\t\t\tt\n\n(I) would be nicer, but propably more difficult the way git-svn works now.\n\n(II) would also be possible and more in line what other people importing\n from SVN see.\n\nThese are the possible ways to describe the merge of 2 SVN branches.\n\n-Peter\n"},{"id":"50234","messageId":"20070808205731.GF27470@xp.machine.xx","threadId":"9431","inReplyTo":"20070808192537.GB27470@xp.machine.xx","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-08-08T20:57:31Z","receivedAt":"2007-08-08T20:57:31Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Wed, Aug 08, 2007 at 09:25:37PM +0200, Peter Baumann wrote:\n> On Wed, Aug 08, 2007 at 08:51:55PM +0200, Matthias Kleine wrote:\n> > Junio C Hamano wrote:\n> >> Parents' order and which branch you are on may not have anything\n> >> to do with each other. Somebody else may have pulled a while on\n> >> b, and you might have pulled from him the merge he created by\n> >> doing so while you are on branch a.\n> >\n> > You're right, I didn't think of that. While pondering this I came up with\n> > another problem: git-svn currently remembers which svn-branch a commit\n> > belongs to by including this information in the git commit log message.\n> \n> Thats true.\n> \n> > This way it is not possible to have one git-commit appear in more than one\n> > svn branch.\n> \n> But there is no way that a git commit could appear on several branches\n> in SVN, because SVN doesn't have the concept of multiple parents. So you\n> can't have a commit which describes a merge of two branches, because SVN\n> can't store the 2 parents. But you could have 2 commits which describe\n> the same state (e.g. same root tree), but are on seperate branches.\n> \n> t:= commits on trunk\n> b:= commits on branch 'b'\n> \n> repo1:\n> \tt <-trunk\n> \t|\n> \tt\n> \t| \\\n> \tt b <- branch\n> \t| /\n> \tt\n> \n> But this graph is only local to the committers repo. Another person\n> using git-svn to track the SVN repo sees this\n> \n> repo2/SVN repo:\n> \n> \tt <-trunk\n> \t|\n> \tt\n> \t|\n> \tt b <- branch\n> \t| /\n> \tt\n> \n> So if you do a 'git merge trunk' in repo1 on branch 'branch', git-svn\n> should produce something like this:\n> \n> repo2/SVN repo:\n> \n> trunk->\tt t' <- branch\n> \t| |\n> \tt t'\n> \t| |\n> \tt b\n> \t| /\n> \tt\n> \n> The interesting case is what it will produce in *YOUR* repo. There are 2\n ^- should, because both cases aren't\n\t\t\t\t implemented yet.\n> possibilities:\n> \n> repo1 (I):\t\t\t\trepo1 (II)\n> \ttb <-trunk <-branch\t\ttrunk->\tt b <- branch\n> \t|\t\t\t\t\t| |\n> \ttb\t\t\t\t\tt b\n> \t| \\\t\t\t\t\t| \\|\n> \tt b <- branch\t\t\t\tt b\n> \t| /\t\t\t\t\t| /\n> \tt\t\t\t\t\tt\n> \n> (I) would be nicer, but propably more difficult the way git-svn works now.\n> \n> (II) would also be possible and more in line what other people importing\n> from SVN see.\n> \n> These are the possible ways to describe the merge of 2 SVN branches.\n> \n-Peter\n"},{"id":"50860","messageId":"20070816082110.GB16849@muzzle","threadId":"9431","inReplyTo":"20070807205543.GB27703@xp.machine.xx","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-16T08:21:10Z","receivedAt":"2007-08-16T08:21:10Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Peter Baumann wrote:\n> On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:\n> > Hi there,\n> >\n> > when running \"git-svn dcommit\" git-svn tries to find the svn-URL of the \n> > current branch int git by looking for the most recent git log-entry \n> > corresponding to a commit in svn (see working_head_info in git-svn). In \n> > case a merge just happended this might be the URL of another branch. Would \n> > using \"log --first-parent\" instead of a plain \"log\" take care of this \n> > problem or would it have other undesirable consequences?\n> >\n> \n> I had this situation, too.\n> \n> \n> \t\t\ta = svn branch 'a'\n> \tm\t\tb = svn branch 'b' (in my case, it was trunk)\n> / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n> a b\n> \n> So trying to dcommit m, git svn can't figure out on which branch, as 'a'\n> and 'b' are both reachable. I had to use a graft file to lose one of the\n> parents, which let git-svn commit to SVN.\n> \n> So for a short fix to get the work done, you could create a graft file\n> where you fake m to only have one parent.\n\nOk. I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.\n\nIt doesn't introduce the problem, but it does encourage it. I still\nhappen to believe allowing git-merges in repositories that try to\ninteroperate with SVN is just giving rope for users to hang themselves\nwith.\n\n\nJunio:\nWould you object to having git-merge spew a big fat warning\nand/or outright refuse to let git-merge run on git-svn repositories?\n\n\n13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using\ngit-format-patch + git-am to apply patches from other branches in SVN,\nwhich is the recommended way to do \"merging\" with git-svn.\n\n> On the longer run, I would make sense to have an option to explicitly\n> specify on which SVN branch 'git-svn dcommit' should operate.\n\nPatches welcome :)\n\n-- \nEric Wong\n"},{"id":"50882","messageId":"20070816121636.GC4499@xp.machine.xx","threadId":"9431","inReplyTo":"20070816082110.GB16849@muzzle","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-08-16T12:16:36Z","receivedAt":"2007-08-16T12:16:36Z","isPatch":false,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:\n> Peter Baumann wrote:\n> > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:\n> > > Hi there,\n> > >\n> > > when running \"git-svn dcommit\" git-svn tries to find the svn-URL of the \n> > > current branch int git by looking for the most recent git log-entry \n> > > corresponding to a commit in svn (see working_head_info in git-svn). In \n> > > case a merge just happended this might be the URL of another branch. Would \n> > > using \"log --first-parent\" instead of a plain \"log\" take care of this \n> > > problem or would it have other undesirable consequences?\n> > >\n> > \n> > I had this situation, too.\n> > \n> > \n> > \t\t\ta = svn branch 'a'\n> > m\t\tb = svn branch 'b' (in my case, it was trunk)\n> > / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n> > a b\n> > \n> > So trying to dcommit m, git svn can't figure out on which branch, as 'a'\n> > and 'b' are both reachable. I had to use a graft file to lose one of the\n> > parents, which let git-svn commit to SVN.\n> > \n> > So for a short fix to get the work done, you could create a graft file\n> > where you fake m to only have one parent.\n> \n> Ok. I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.\n> \n> It doesn't introduce the problem, but it does encourage it. I still\n> happen to believe allowing git-merges in repositories that try to\n> interoperate with SVN is just giving rope for users to hang themselves\n> with.\n> \n> \n> Junio:\n> Would you object to having git-merge spew a big fat warning\n> and/or outright refuse to let git-merge run on git-svn repositories?\n> \n\nBy removing merges in git-svn, it would lose much of its 'magic'. I have\nto mainain a SVN branch and from time to time, I merge with trunk. So\nit'll totally screw me if I lose the merge history (sure, I could use\na graft file, but a real merge is preferable, because I can clone the\nrepo then).\n\n> \n> 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using\n> git-format-patch + git-am to apply patches from other branches in SVN,\n> which is the recommended way to do \"merging\" with git-svn.\n> \nHm. What about cherry pick? I ask because a friend of mine messed up the\nSVN repo after cherry picking a commit from 'trunk' and then his next\ndcommit put everything into 'trunk' instead of his own branch (hopefully,\nI remembered correctly; but at least I know for sure a cherry pick from\ntrunk was involved). I can't ask him right now, because he is on\nvacation till monday, but I'll Cc him, just in case.\n\n-Peter\n"},{"id":"50920","messageId":"20070817075549.GE16849@muzzle","threadId":"9431","inReplyTo":"20070816121636.GC4499@xp.machine.xx","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-17T07:55:49Z","receivedAt":"2007-08-17T07:55:49Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Peter Baumann wrote:\n> On Thu, Aug 16, 2007 at 01:21:10AM -0700, Eric Wong wrote:\n> > Peter Baumann wrote:\n> > > On Tue, Aug 07, 2007 at 08:29:23PM +0200, Matthias Kleine wrote:\n> > > > Hi there,\n> > > >\n> > > > when running \"git-svn dcommit\" git-svn tries to find the svn-URL of the \n> > > > current branch int git by looking for the most recent git log-entry \n> > > > corresponding to a commit in svn (see working_head_info in git-svn). In \n> > > > case a merge just happended this might be the URL of another branch. Would \n> > > > using \"log --first-parent\" instead of a plain \"log\" take care of this \n> > > > problem or would it have other undesirable consequences?\n> > > >\n> > > \n> > > I had this situation, too.\n> > > \n> > > \n> > > \t\t\ta = svn branch 'a'\n> > > m\t\tb = svn branch 'b' (in my case, it was trunk)\n> > > / \\\t\tm = a merge of branch 'a' and 'b', not yet commited to svn\n> > > a b\n> > > \n> > > So trying to dcommit m, git svn can't figure out on which branch, as 'a'\n> > > and 'b' are both reachable. I had to use a graft file to lose one of the\n> > > parents, which let git-svn commit to SVN.\n> > > \n> > > So for a short fix to get the work done, you could create a graft file\n> > > where you fake m to only have one parent.\n> > \n> > Ok. I'm regretting making 733a65aa5d33196fac708ebd12a98a1060cbf3c2 now.\n> > \n> > It doesn't introduce the problem, but it does encourage it. I still\n> > happen to believe allowing git-merges in repositories that try to\n> > interoperate with SVN is just giving rope for users to hang themselves\n> > with.\n> > \n> > \n> > Junio:\n> > Would you object to having git-merge spew a big fat warning\n> > and/or outright refuse to let git-merge run on git-svn repositories?\n> \n> By removing merges in git-svn, it would lose much of its 'magic'. I have\n> to mainain a SVN branch and from time to time, I merge with trunk. So\n> it'll totally screw me if I lose the merge history (sure, I could use\n> a graft file, but a real merge is preferable, because I can clone the\n> repo then).\n\nOk, outright refusing to merge/pull is probably too much. But spewing\na big warning may help.\n\n> > 13c823fb520eaf1cded520213cf0ae4c3268208d was introduced to allow using\n> > git-format-patch + git-am to apply patches from other branches in SVN,\n> > which is the recommended way to do \"merging\" with git-svn.\n> > \n> Hm. What about cherry pick? I ask because a friend of mine messed up the\n> SVN repo after cherry picking a commit from 'trunk' and then his next\n> dcommit put everything into 'trunk' instead of his own branch (hopefully,\n> I remembered correctly; but at least I know for sure a cherry pick from\n> trunk was involved). I can't ask him right now, because he is on\n> vacation till monday, but I'll Cc him, just in case.\n\nYeah, cherry-pick works, too. I've never actually used cherry-pick\nmyself, because git-format-patch and git-am let me work on a series of\npatches rather than one-at-a-time.\n\n-- \nEric Wong\n"},{"id":"50924","messageId":"7vir7eh7mc.fsf@gitster.siamese.dyndns.org","threadId":"9431","inReplyTo":"20070816082110.GB16849@muzzle","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-17T08:45:31Z","receivedAt":"2007-08-17T08:45:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> Junio:\n> Would you object to having git-merge spew a big fat warning\n> and/or outright refuse to let git-merge run on git-svn repositories?\n\nActually I do. A major, if not primary, selling point of\ngit-svn has been that svn cannot do merges but if you import to\ngit you can, and I've had an impression that Sam's git-svn intro\nalludes to this capability as well.\n\nIf I understand you correctly, your position is that the svn\nside has the authoritative history when using git-svn, and we\nshould refuse to do anything on the git side that the resulting\nhistory in svn cannot represent. I know and respect that you\nhave thought about the issues involved long enough before that\ndeclaration of defeat, but at the same time, I would really hope\nthat we can come up with a workable compromise to allow merge\ntracking on the git side.\n\nIt probably does not even have to interoperate with people who\ndo their own merge tracking using svk. Perhaps something as\nsimple and ugly as recording the parent commit object names on\nthe git side as a trailer to the commit log message we push back\nto svn would allow people who interact with the same svn\nrepository from their own git-svn managed git repository to\ninteroperate with each other?\n"},{"id":"50974","messageId":"20070818090913.GA13936@soma","threadId":"9431","inReplyTo":"7vir7eh7mc.fsf@gitster.siamese.dyndns.org","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-08-18T09:09:13Z","receivedAt":"2007-08-18T09:09:13Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > Junio:\n> > Would you object to having git-merge spew a big fat warning\n> > and/or outright refuse to let git-merge run on git-svn repositories?\n> \n> Actually I do. A major, if not primary, selling point of\n> git-svn has been that svn cannot do merges but if you import to\n> git you can, and I've had an impression that Sam's git-svn intro\n> alludes to this capability as well.\n\nWow. My primary reasons for git-svn are completely different: speed and\noffline usability; and merging was not so much a concern for me.\n\nI've grown to prefer the patch + rebase model of keeping history linear\nin my work. This is different than from when I first picked up git:\nwent overboard on merging just to see what kind of interesting graphs I\ncould create in gitk :)\n\nSo I didn't always prefer the recommended way git-svn works now. In the\nbeginning there was the \"git-svn commit\" command, which has now been\nnamed \"set-tree\". I haven't used set-tree in ages, but I think it still\nsupports preserving history of a git <-> git merging after commiting to\nSVN. The problem with set-tree was that it would either:\n\na) make history ugly (with duplicate commits) for git users, as history\n never gets rewritten when using set-tree.\n\nor\n\nb) hide history from SVN users.\n\n> If I understand you correctly, your position is that the svn\n> side has the authoritative history when using git-svn, and we\n> should refuse to do anything on the git side that the resulting\n> history in svn cannot represent. I know and respect that you\n> have thought about the issues involved long enough before that\n> declaration of defeat, but at the same time, I would really hope\n> that we can come up with a workable compromise to allow merge\n> tracking on the git side.\n\nYes. From what I gather, developers only use git-svn because they don't\nhave enough swing within their group to replace SVN. I don't think\nencouraging git-svn users to isolate themselves with their own history\nand propagating less-useful history to the non-SVN users in a project is\na good thing.\n\n> It probably does not even have to interoperate with people who\n> do their own merge tracking using svk. Perhaps something as\n> simple and ugly as recording the parent commit object names on\n> the git side as a trailer to the commit log message we push back\n> to svn would allow people who interact with the same svn\n> repository from their own git-svn managed git repository to\n> interoperate with each other?\n\nOf course, git-svn has gotten a lot more users than I expected it\nwould, so maybe I'll implement it and see where it takes us.\n\nThis could just be as simple as using the code for set-tree and instead\nusing it to create revprops in SVN. I'd probably be inventing a fourth\nmethod of doing merge-tracking in SVN, though...\n\n-- \nEric Wong\n"},{"id":"50977","messageId":"85fy2hupui.fsf@lola.goethe.zz","threadId":"9431","inReplyTo":"20070818090913.GA13936@soma","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-18T09:57:57Z","receivedAt":"2007-08-18T09:57:57Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Eric Wong writes:\n\n> Junio C Hamano wrote:\n>\n>> Actually I do. A major, if not primary, selling point of\n>> git-svn has been that svn cannot do merges but if you import to\n>> git you can, and I've had an impression that Sam's git-svn intro\n>> alludes to this capability as well.\n>\n> Wow. My primary reasons for git-svn are completely different: speed\n> and offline usability; and merging was not so much a concern for me.\n>\n>> If I understand you correctly, your position is that the svn side\n>> has the authoritative history when using git-svn, and we should\n>> refuse to do anything on the git side that the resulting history in\n>> svn cannot represent. I know and respect that you have thought\n>> about the issues involved long enough before that declaration of\n>> defeat, but at the same time, I would really hope that we can come\n>> up with a workable compromise to allow merge tracking on the git\n>> side.\n>\n> Yes. From what I gather, developers only use git-svn because they\n> don't have enough swing within their group to replace SVN.\n\nNot at all. Subversion has _working_ subproject support (which is\nrather easy, since every directory is treated the same and you can\nmerge at every level). It also has other tools like \"Trac\". And it\nprovides a _stable_ history and point of reference and backup. While\nI appreciate being able to create and undo almost any mess in my\npersonal git repository (and this happens not infrequently), I would\nnot want to propose that to everybody.\n\ngit-svn makes it possible for me to keep the mess that is git to\nmyself, and only expose others to the _results_ of my work with it.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"50979","messageId":"7vmywpcg63.fsf@gitster.siamese.dyndns.org","threadId":"9431","inReplyTo":"85fy2hupui.fsf@lola.goethe.zz","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-18T10:04:20Z","receivedAt":"2007-08-18T10:04:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> git-svn makes it possible for me to keep the mess that is git to\n> myself, and only expose others to the _results_ of my work with it.\n\nVery well put. It is not just svn but I privately use git on\ntop of cvs managed project for exactly this reason.\n"},{"id":"50985","messageId":"20070818211825.GA18252@diana.vm.bytemark.co.uk","threadId":"9431","inReplyTo":"7vmywpcg63.fsf@gitster.siamese.dyndns.org","subject":"Re: git-svn: Finding the svn-URL of the current branch in git","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-08-18T21:18:25Z","receivedAt":"2007-08-18T21:18:25Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-08-18 03:04:20 -0700, Junio C Hamano wrote:\n\n> David Kastrup writes:\n>\n> > git-svn makes it possible for me to keep the mess that is git to\n> > myself, and only expose others to the _results_ of my work with\n> > it.\n>\n> Very well put. It is not just svn but I privately use git on top of\n> cvs managed project for exactly this reason.\n\nI use git (and git-svn, and StGIT) on top of our Subversion repository\nat work for this reason too: git lets me rewrite recent history until\nit's pretty, while svn considers history totally immutable (barring a\ndump+filter+reload of the whole (central) repository).\n\nHowever, I object to the insinuation (in David's post, if not yours)\nthat \"history in git is a mess\" because it's mutable. git lets you set\nthe policy for each of your branches: either allow history editing (to\nbe able to fix embarrassing mistakes), or don't (to let people rely on\nhistory to not change under their feet). This is strictly better than\nSubversion, which forces you to adopt the latter policy.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"}]}