{"thread":{"id":"8507","subject":"git-svn set-tree bug","startedAt":"2007-06-08T17:25:15Z","lastAt":"2007-07-01T13:09:44Z","messageCount":27,"participants":["Joakim Tjernlund","Eric Wong","Steven Grimm","Junio C Hamano","Lars Hjemli"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"44363","messageId":"1181323515.30670.110.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":null,"subject":"git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-08T17:25:15Z","receivedAt":"2007-06-08T17:25:15Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"trying to do git-svn set-tree remotes/trunk..svn\nin my new git-svn repo I get:\nconfig --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1\n\ngit version 1.5.2.1\n"},{"id":"44524","messageId":"20070610014734.GA542@muzzle","threadId":"8507","inReplyTo":"1181323515.30670.110.camel@gentoo-jocke.transmode.se","subject":"Re: git-svn set-tree bug","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-10T01:47:34Z","receivedAt":"2007-06-10T01:47:34Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Joakim Tjernlund wrote:\n> trying to do git-svn set-tree remotes/trunk..svn\n> in my new git-svn repo I get:\n> config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1\n\nYou need to specify \"-i trunk\" in the command-line\n\ngit-svn set-tree -i trunk remotes/trunk..svn\n\n-- \nEric Wong\n"},{"id":"44622","messageId":"1181496086.30670.115.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"20070610014734.GA542@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-10T17:21:26Z","receivedAt":"2007-06-10T17:21:26Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:\n> Joakim Tjernlund wrote:\n> > trying to do git-svn set-tree remotes/trunk..svn\n> > in my new git-svn repo I get:\n> > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1\n> \n> You need to specify \"-i trunk\" in the command-line\n> \n> git-svn set-tree -i trunk remotes/trunk..svn\n> \n\nThanks\n\nI have found a bug or two. Run this script and\nsee what happens ant the end.\nrm -rf mygitsvn\nrm -rf mysvnrepo\nrm -rf mysvnwork\nmkdir mysvnrepo\ncd mysvnrepo\nsvnadmin create .\ncd ..\nsvn checkout file:///$PWD/mysvnrepo mysvnwork\nmkdir -p mysvnwork/trunk\ncd mysvnwork/\ncat << EOF > trunk/README\n#\n# (C) Copyright 2000 - 2005\n# Wolfgang Denk, DENX Software Engineering, wd@denx.de.\n#\n# See file CREDITS for list of people who contributed to this\n# project.\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License as\n# published by the Free Software Foundation; either version 2 of\n# the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\tSee the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 59 Temple Place, Suite 330, Boston,\n# MA 02111-1307 USA\n#\n\nEOF\n\nsvn add trunk\nsvn ci -m \"first commit\" trunk\ncd ..\ngit-svn clone file:///$PWD/mysvnrepo -t tags -T trunk -b branches\nmygitsvn\ncd mygitsvn\n\ngit checkout --track -b svn remotes/trunk\ngit checkout -b merge\necho new file > new_file\ngit add new_file\ngit commit -a -m \"New file\"\n\necho hello >> README\ngit commit -a -m \"hello\"\n\necho add some stuff >> new_file\ngit commit -a -m \"add some stuff\"\n\ngit checkout svn\nmv -f README tmp\necho friend > README\ncat tmp >> README\ngit commit -a -m \"friend\"\ngit pull . merge\ngit svn dcommit # this fails \ngit svn rebase \n# this fails too, mismerges the last commit and remove the merge commit\n"},{"id":"44623","messageId":"1181496458.30670.117.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"1181496086.30670.115.camel@gentoo-jocke.transmode.se","subject":"Re: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-10T17:27:38Z","receivedAt":"2007-06-10T17:27:38Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Sun, 2007-06-10 at 19:21 +0200, Joakim Tjernlund wrote:\n> On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:\n> > Joakim Tjernlund wrote:\n> > > trying to do git-svn set-tree remotes/trunk..svn\n> > > in my new git-svn repo I get:\n> > > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1\n> > \n> > You need to specify \"-i trunk\" in the command-line\n> > \n> > git-svn set-tree -i trunk remotes/trunk..svn\n> > \n> \n> Thanks\n\n[SNIP script]\n\nforgot:\n git version 1.5.2.1\n subversion version 1.4.3\n\n Jocke\n"},{"id":"44643","messageId":"20070610213322.GB12222@muzzle","threadId":"8507","inReplyTo":"1181496086.30670.115.camel@gentoo-jocke.transmode.se","subject":"Re: git-svn set-tree bug","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-10T21:33:22Z","receivedAt":"2007-06-10T21:33:22Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Joakim Tjernlund wrote:\n> On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:\n> > Joakim Tjernlund wrote:\n> > > trying to do git-svn set-tree remotes/trunk..svn\n> > > in my new git-svn repo I get:\n> > > config --get svn-remote.svn.fetch :refs/remotes/git-svn$: command returned error: 1\n> > \n> > You need to specify \"-i trunk\" in the command-line\n> > \n> > git-svn set-tree -i trunk remotes/trunk..svn\n> > \n> \n> Thanks\n> \n> I have found a bug or two. Run this script and\n> see what happens ant the end.\n\n\n\n> git pull . merge\n\nThis is a non-fast-forward merge, giving you non-linear history. git\nunderstands non-linear history without problems, but svn does not.\n\n> git svn dcommit # this fails \n\nIf you have non-linear history, don't use dcommit, use set-tree. Linear\nhistory is cleaner and easier to manage, which is why I recommend\nformat-patch/am/dcommit/rebase, and avoid using pull/merge unless it's\nfast-forward.\n\n-- \nEric Wong\n"},{"id":"44663","messageId":"002a01c7abb6$de2b3680$0e67a8c0@Jocke","threadId":"8507","inReplyTo":"20070610213322.GB12222@muzzle","subject":"RE: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-10T23:27:09Z","receivedAt":"2007-06-10T23:27:09Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":" \n\n> -----Original Message-----\n> From: Eric Wong [mailto:normalperson@yhbt.net] \n> Sent: den 10 juni 2007 23:33\n> To: Joakim Tjernlund\n> Cc: git\n> Subject: Re: git-svn set-tree bug\n> \n> Joakim Tjernlund wrote:\n> > On Sat, 2007-06-09 at 18:47 -0700, Eric Wong wrote:\n> > > Joakim Tjernlund wrote:\n> > > > trying to do git-svn set-tree remotes/trunk..svn\n> > > > in my new git-svn repo I get:\n> > > > config --get svn-remote.svn.fetch \n> :refs/remotes/git-svn$: command returned error: 1\n> > > \n> > > You need to specify \"-i trunk\" in the command-line\n> > > \n> > > git-svn set-tree -i trunk remotes/trunk..svn\n> > > \n> > \n> > Thanks\n> > \n> > I have found a bug or two. Run this script and\n> > see what happens ant the end.\n> \n> \n> \n> > git pull . merge\n> \n> This is a non-fast-forward merge, giving you non-linear history. git\n> understands non-linear history without problems, but svn does not.\n> \n> > git svn dcommit # this fails \n> \n> If you have non-linear history, don't use dcommit, use \n> set-tree. Linear\n> history is cleaner and easier to manage, which is why I recommend\n> format-patch/am/dcommit/rebase, and avoid using pull/merge unless it's\n> fast-forward.\n\nI see, I figured git-svn could work around that.\nSo I should do a git svn set-tree -i trunk remotes/trunk..svn\nand then git svn rebase? That makes the git history hard to\nfollow.\nhmm, is it wise to mix set-tree and dcommit in one repo?\nIs there a way to tell set-tree to commit the whole \"merge\" branch\nas one svn commit?\nIf I merge the latest kernel into my tree there will\nbe a lot of commits that I don't want in svn.\n\n Jocke\n\n\n Jocke\n"},{"id":"44666","messageId":"466C8B35.3020207@midwinter.com","threadId":"8507","inReplyTo":"002a01c7abb6$de2b3680$0e67a8c0@Jocke","subject":"Re: git-svn set-tree bug","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-10T23:37:25Z","receivedAt":"2007-06-10T23:37:25Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Joakim Tjernlund wrote:\n> Is there a way to tell set-tree to commit the whole \"merge\" branch\n> as one svn commit?\n> If I merge the latest kernel into my tree there will\n> be a lot of commits that I don't want in svn.\n> \n\nYou want a \"squash\" merge. Something like this:\n\ngit checkout -b tempbranch origin/svn-branch-to-commit-merge-to\ngit merge --squash branch-with-commits-you-want-to-merge\ngit commit\ngit svn dcommit\n\nThe \"merge\" command will merge in the changes but will not commit \nanything; when you do the explicit \"commit\" command afterwards, you get \nthe contents of the merge but from git's point of view it's just a \nregular commit so git-svn doesn't get confused.\n\nAfter you do git svn dcommit, you may want to edit .git/info/grafts to \ntell git after the fact that this commit was a merge. It won't hurt \ngit-svn at that point and it will mean you can do another merge later \nwithout git getting confused about what has already been merged.\n\nTake a look at the script I posted a while back, which does something \nsimilar:\n\nhttp://www.spinics.net/lists/git/msg29119.html\n\n-Steve\n"},{"id":"44667","messageId":"003401c7abba$c7574300$0e67a8c0@Jocke","threadId":"8507","inReplyTo":"466C8B35.3020207@midwinter.com","subject":"RE: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-10T23:55:09Z","receivedAt":"2007-06-10T23:55:09Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":" \n\n> -----Original Message-----\n> From: Steven Grimm [mailto:koreth@midwinter.com] \n> Sent: den 11 juni 2007 01:37\n> To: Joakim Tjernlund\n> Cc: 'Eric Wong'; 'git'\n> Subject: Re: git-svn set-tree bug\n> \n> Joakim Tjernlund wrote:\n> > Is there a way to tell set-tree to commit the whole \"merge\" branch\n> > as one svn commit?\n> > If I merge the latest kernel into my tree there will\n> > be a lot of commits that I don't want in svn.\n> > \n> \n> You want a \"squash\" merge. Something like this:\n> \n> git checkout -b tempbranch origin/svn-branch-to-commit-merge-to\n> git merge --squash branch-with-commits-you-want-to-merge\n> git commit\n> git svn dcommit\n> \n> The \"merge\" command will merge in the changes but will not commit \n> anything; when you do the explicit \"commit\" command \n> afterwards, you get \n> the contents of the merge but from git's point of view it's just a \n> regular commit so git-svn doesn't get confused.\n> \n> After you do git svn dcommit, you may want to edit \n> .git/info/grafts to \n> tell git after the fact that this commit was a merge. It won't hurt \n> git-svn at that point and it will mean you can do another merge later \n> without git getting confused about what has already been merged.\n> \n> Take a look at the script I posted a while back, which does something \n> similar:\n> \n> http://www.spinics.net/lists/git/msg29119.html\n> \n\nHi Steven\n\nThat looks promising, especially Junos comment about making git-svn\nable to deal with merges. Eric, do you feel this is doable?\n\n Jocke \n"},{"id":"44687","messageId":"20070611042509.GA19866@muzzle","threadId":"8507","inReplyTo":"003401c7abba$c7574300$0e67a8c0@Jocke","subject":"Re: git-svn set-tree bug","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-11T04:25:09Z","receivedAt":"2007-06-11T04:25:09Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Joakim Tjernlund wrote:\n> > -----Original Message-----\n> > From: Steven Grimm [mailto:koreth@midwinter.com] \n> > Sent: den 11 juni 2007 01:37\n> > To: Joakim Tjernlund\n> > Cc: 'Eric Wong'; 'git'\n> > Subject: Re: git-svn set-tree bug\n> > \n> > Joakim Tjernlund wrote:\n> > > Is there a way to tell set-tree to commit the whole \"merge\" branch\n> > > as one svn commit?\n> > > If I merge the latest kernel into my tree there will\n> > > be a lot of commits that I don't want in svn.\n> > > \n> > \n> > You want a \"squash\" merge. Something like this:\n> > \n> > git checkout -b tempbranch origin/svn-branch-to-commit-merge-to\n> > git merge --squash branch-with-commits-you-want-to-merge\n> > git commit\n> > git svn dcommit\n> > \n> > The \"merge\" command will merge in the changes but will not commit \n> > anything; when you do the explicit \"commit\" command \n> > afterwards, you get \n> > the contents of the merge but from git's point of view it's just a \n> > regular commit so git-svn doesn't get confused.\n> > \n> > After you do git svn dcommit, you may want to edit \n> > .git/info/grafts to \n> > tell git after the fact that this commit was a merge. It won't hurt \n> > git-svn at that point and it will mean you can do another merge later \n> > without git getting confused about what has already been merged.\n> > \n> > Take a look at the script I posted a while back, which does something \n> > similar:\n> > \n> > http://www.spinics.net/lists/git/msg29119.html\n\nI must have missed this message the first time around.\n\n> Hi Steven\n> \n> That looks promising, especially Junos comment about making git-svn\n> able to deal with merges. Eric, do you feel this is doable?\n\nDoable? Yes. However, I think using grafts is quite hackish and\nunreliable[1]. I'd rather just have users using set-tree if\nthey want to deal with non-linear history in the first place.\n\nI'd personally avoid any sort of non-linear history when interacting\nwith SVN repositories, however.\n\n[1] - as far as I know, graft files have no verification/protection\n against corruption. They don't get cloned, either.\n\n-- \nEric Wong\n"},{"id":"44693","messageId":"7vir9vox5l.fsf@assigned-by-dhcp.cox.net","threadId":"8507","inReplyTo":"20070611042509.GA19866@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-06-11T05:52:38Z","receivedAt":"2007-06-11T05:52:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> Joakim Tjernlund wrote:\n>> > -----Original Message-----\n>> > From: Steven Grimm [mailto:koreth@midwinter.com] \n>> > Sent: den 11 juni 2007 01:37\n>> > To: Joakim Tjernlund\n>> > Cc: 'Eric Wong'; 'git'\n>> > Subject: Re: git-svn set-tree bug\n>> > \n>> > Joakim Tjernlund wrote:\n>> > > Is there a way to tell set-tree to commit the whole \"merge\" branch\n>> > > as one svn commit?\n>> > > If I merge the latest kernel into my tree there will\n>> > > be a lot of commits that I don't want in svn.\n>> > > \n>> > \n>> > You want a \"squash\" merge. Something like this:\n>> > \n>> > git checkout -b tempbranch origin/svn-branch-to-commit-merge-to\n>> > git merge --squash branch-with-commits-you-want-to-merge\n>> > git commit\n>> > git svn dcommit\n>> > \n>> > The \"merge\" command will merge in the changes but will not commit \n>> > anything; when you do the explicit \"commit\" command \n>> > afterwards, you get \n>> > the contents of the merge but from git's point of view it's just a \n>> > regular commit so git-svn doesn't get confused.\n>> > \n>> > After you do git svn dcommit, you may want to edit \n>> > .git/info/grafts to \n>> > tell git after the fact that this commit was a merge. It won't hurt \n>> > git-svn at that point and it will mean you can do another merge later \n>> > without git getting confused about what has already been merged.\n>> > \n>> > Take a look at the script I posted a while back, which does something \n>> > similar:\n>> > \n>> > http://www.spinics.net/lists/git/msg29119.html\n>\n> I must have missed this message the first time around.\n>\n>> Hi Steven\n>> \n>> That looks promising, especially Junos comment about making git-svn\n>> able to deal with merges. Eric, do you feel this is doable?\n>\n> Doable? Yes. However, I think using grafts is quite hackish and\n> unreliable[1]. I'd rather just have users using set-tree if\n> they want to deal with non-linear history in the first place.\n>\n> I'd personally avoid any sort of non-linear history when interacting\n> with SVN repositories, however.\n\nI've been wondering if you can do a moral equilvalent of the\ngraft trick but without using graft inside dcommit. Perform a\nmerge --squash of the other branch (call the tip commit $B),\nthen dcommit on the git side as usual, and call it commit $C.\nSteven's procedure would do a graft trick here, but instead of\ndoing that, rewrite $C to have the two parents. Using the tree\nobject of $C, create a new git commit $D that is a merge between\nthe parent of $C (i.e. $C^) and the squashed branch tip $B.\nReplace the tip of the current branch (which is $C) with $D.\nFinally, replace the mapping between svn commit and git side\nrecorded in the revdb (which currently says $C on the git side\ncorresponds to the HEAD of SVN side) with this new commit $D.\n\nWouldn't that let the git side know what was merged into the\nbranch, so that later merges on the git side would go smoothly?\n\nOr am I grossly misunderstanding how dcommit, tracking of svn vs\ngit commit mappings and the graft trick work?\n"},{"id":"44698","messageId":"466CF2A0.4080604@midwinter.com","threadId":"8507","inReplyTo":"20070611042509.GA19866@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-11T06:58:40Z","receivedAt":"2007-06-11T06:58:40Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Eric Wong wrote:\n> Doable? Yes. However, I think using grafts is quite hackish and\n> unreliable[1]. I'd rather just have users using set-tree if\n> they want to deal with non-linear history in the first place.\n> \n\nAgreed about grafts being hackish and unreliable. But they were what I \nhad to work with, given that I know little enough about git-svn's \ninternals to be able to implement Junio's more robust idea.\n\nIMO set-tree is not much of an option. In my environment it is \nunacceptable for there to be any possibility of accidentally and \nsilently overwriting some other change that just happened to hit the svn \nrepo right before I committed my change, which (unless it has changed \nsince I last tried it) set-tree will happily do. I can get away with \ndoing that maybe once before my company's release manager will, quite \njustifiably, require me to stop using git and switch back to the \nstandard svn client.\n\n> I'd personally avoid any sort of non-linear history when interacting\n> with SVN repositories, however.\n> \n\nWhich is a shame since git loses a lot of its utility without nonlinear \nhistory. For example, the script I posted uses git to do merges between \nsvn branches. It works wonderfully even if, as you and Junio point out, \nits use of grafts to record svn merges scales poorly and is potentially \nsusceptible to corruption. Thanks to the ability to record the fact that \nmy merges between svn branches were actually merges, my git clone has a \nmore complete picture of what's in my svn repository than the svn \nrepository itself does!\n\n-Steve\n"},{"id":"44707","messageId":"1181551957.30670.154.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"466CF2A0.4080604@midwinter.com","subject":"Re: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-11T08:52:37Z","receivedAt":"2007-06-11T08:52:37Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Sun, 2007-06-10 at 23:58 -0700, Steven Grimm wrote:\n> Eric Wong wrote:\n> > Doable? Yes. However, I think using grafts is quite hackish and\n> > unreliable[1]. I'd rather just have users using set-tree if\n> > they want to deal with non-linear history in the first place.\n> > \n> \n> Agreed about grafts being hackish and unreliable. But they were what I \n> had to work with, given that I know little enough about git-svn's \n> internals to be able to implement Junio's more robust idea.\n> \n> IMO set-tree is not much of an option. In my environment it is \n> unacceptable for there to be any possibility of accidentally and \n> silently overwriting some other change that just happened to hit the svn \n> repo right before I committed my change, which (unless it has changed \n> since I last tried it) set-tree will happily do. I can get away with \n> doing that maybe once before my company's release manager will, quite \n> justifiably, require me to stop using git and switch back to the \n> standard svn client.\n> \n> > I'd personally avoid any sort of non-linear history when interacting\n> > with SVN repositories, however.\n> > \n> \n> Which is a shame since git loses a lot of its utility without nonlinear \n> history. For example, the script I posted uses git to do merges between \n> svn branches. It works wonderfully even if, as you and Junio point out, \n> its use of grafts to record svn merges scales poorly and is potentially \n> susceptible to corruption. Thanks to the ability to record the fact that \n> my merges between svn branches were actually merges, my git clone has a \n> more complete picture of what's in my svn repository than the svn \n> repository itself does!\n\nExactly, I too think that this is a much needed feature for git-svn.\n\nI have also noted that this modified(added a git svn dcommit) script \nworks:\nrm -rf mygitsvn\nrm -rf mysvnrepo\nrm -rf mysvnwork\nmkdir mysvnrepo\ncd mysvnrepo\nsvnadmin create .\ncd ..\nsvn checkout file:///$PWD/mysvnrepo mysvnwork\nmkdir -p mysvnwork/trunk\ncd mysvnwork/\ncat << EOF > trunk/README\n#\n# (C) Copyright 2000 - 2005\n# Wolfgang Denk, DENX Software Engineering, wd@denx.de.\n#\n# See file CREDITS for list of people who contributed to this\n# project.\n#\n# This program is free software; you can redistribute it and/or\n# modify it under the terms of the GNU General Public License as\n# published by the Free Software Foundation; either version 2 of\n# the License, or (at your option) any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\tSee the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, write to the Free Software\n# Foundation, Inc., 59 Temple Place, Suite 330, Boston,\n# MA 02111-1307 USA\n#\n\nEOF\n\nsvn add trunk\nsvn ci -m \"first commit\" trunk\ncd ..\ngit-svn clone file:///$PWD/mysvnrepo -t tags -T trunk -b branches mygitsvn\ncd mygitsvn\n\ngit checkout --track -b svn remotes/trunk\ngit checkout -b merge\necho new file > new_file\ngit add new_file\ngit commit -a -m \"New file\"\n\necho hello >> README\ngit commit -a -m \"hello\"\n\necho add some stuff >> new_file\ngit commit -a -m \"add some stuff\"\n\ngit checkout svn\nmv -f README tmp\necho friend > README\ncat tmp >> README\ngit commit -a -m \"friend\"\ngit svn dcommit\ngit pull . merge\ngit svn dcommit\n\nbut, as expected, then merge commit is still gone.\n"},{"id":"44804","messageId":"20070612072035.GA29385@muzzle","threadId":"8507","inReplyTo":"7vir9vox5l.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-svn set-tree bug","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-12T07:20:35Z","receivedAt":"2007-06-12T07:20:35Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > Joakim Tjernlund wrote:\n> >> > -----Original Message-----\n> >> > From: Steven Grimm [mailto:koreth@midwinter.com] \n> >> > Sent: den 11 juni 2007 01:37\n> >> > To: Joakim Tjernlund\n> >> > Cc: 'Eric Wong'; 'git'\n> >> > Subject: Re: git-svn set-tree bug\n> >> > \n> >> > Joakim Tjernlund wrote:\n> >> > > Is there a way to tell set-tree to commit the whole \"merge\" branch\n> >> > > as one svn commit?\n> >> > > If I merge the latest kernel into my tree there will\n> >> > > be a lot of commits that I don't want in svn.\n> >> > > \n> >> > \n> >> > You want a \"squash\" merge. Something like this:\n> >> > \n> >> > git checkout -b tempbranch origin/svn-branch-to-commit-merge-to\n> >> > git merge --squash branch-with-commits-you-want-to-merge\n> >> > git commit\n> >> > git svn dcommit\n> >> > \n> >> > The \"merge\" command will merge in the changes but will not commit \n> >> > anything; when you do the explicit \"commit\" command \n> >> > afterwards, you get \n> >> > the contents of the merge but from git's point of view it's just a \n> >> > regular commit so git-svn doesn't get confused.\n> >> > \n> >> > After you do git svn dcommit, you may want to edit \n> >> > .git/info/grafts to \n> >> > tell git after the fact that this commit was a merge. It won't hurt \n> >> > git-svn at that point and it will mean you can do another merge later \n> >> > without git getting confused about what has already been merged.\n> >> > \n> >> > Take a look at the script I posted a while back, which does something \n> >> > similar:\n> >> > \n> >> > http://www.spinics.net/lists/git/msg29119.html\n> >\n> > I must have missed this message the first time around.\n> >\n> >> Hi Steven\n> >> \n> >> That looks promising, especially Junos comment about making git-svn\n> >> able to deal with merges. Eric, do you feel this is doable?\n> >\n> > Doable? Yes. However, I think using grafts is quite hackish and\n> > unreliable[1]. I'd rather just have users using set-tree if\n> > they want to deal with non-linear history in the first place.\n> >\n> > I'd personally avoid any sort of non-linear history when interacting\n> > with SVN repositories, however.\n> \n> I've been wondering if you can do a moral equilvalent of the\n> graft trick but without using graft inside dcommit. Perform a\n> merge --squash of the other branch (call the tip commit $B),\n> then dcommit on the git side as usual, and call it commit $C.\n> Steven's procedure would do a graft trick here, but instead of\n> doing that, rewrite $C to have the two parents. Using the tree\n> object of $C, create a new git commit $D that is a merge between\n> the parent of $C (i.e. $C^) and the squashed branch tip $B.\n> Replace the tip of the current branch (which is $C) with $D.\n> Finally, replace the mapping between svn commit and git side\n> recorded in the revdb (which currently says $C on the git side\n> corresponds to the HEAD of SVN side) with this new commit $D.\n> \n> Wouldn't that let the git side know what was merged into the\n> branch, so that later merges on the git side would go smoothly?\n> \n> Or am I grossly misunderstanding how dcommit, tracking of svn vs\n> git commit mappings and the graft trick work?\n\nOk, it took me a few reads, but I think that'll work...\n\nIf dcommit detects a merge commit when doing rev-list When looking at\ncommit objects, is it safe to assume that the first parent is always the\n\"mainline\" and that parents after it are the ones to merge from?\n\nSo if I saw:\n\ncommit $X\nparent $A\nparent $B\n\nI'd basically do:\n reset --hard $A\n merge --squash $B\n\nAnd resulting in $C which would have the same tree as $X,\nthen, when dcommit-ting, $D would be created with two parents:\n $D~1 (svn), $B (git), but not $A\n\nRewritten history:\n $A => $D~1\n $X => $D (HEAD revision in SVN)\n\n$X and $A are now discarded and gc-able.\n\n\nOf course, since I already have the result of \"merge --squash $B\" in $X,\nI could just rewrite $X with a single parent (call it $X'), dcommit, and\nthen give $D ($D~1 and $B) as parents. Avoiding the nastiness of\nset-tree\n\n-- \nEric Wong\n"},{"id":"44805","messageId":"7v1wghlj7j.fsf@assigned-by-dhcp.pobox.com","threadId":"8507","inReplyTo":"20070612072035.GA29385@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T07:34:24Z","receivedAt":"2007-06-12T07:34:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> If dcommit detects a merge commit when doing rev-list When looking at\n> commit objects, is it safe to assume that the first parent is always the\n> \"mainline\" and that parents after it are the ones to merge from?\n>\n> So if I saw:\n>\n> commit $X\n> parent $A\n> parent $B\n>\n> I'd basically do:\n> reset --hard $A\n> merge --squash $B\n>\n> And resulting in $C which would have the same tree as $X,\n> then, when dcommit-ting, $D would be created with two parents:\n> $D~1 (svn), $B (git), but not $A\n\nI am not sure what you mean by \"mainline\", but I assume that you\nmean \"SVN is the main and we are tracking it while taking\nadvantage of more efficient and merge-capable git in guerrilla\nfashion\". Because the tip of the current branch is what the\nuser is pushing back to SVN via dcommit, I would say it is safe\nto assume that the first parent of such a merge is the line that\ncorresponds to the SVN branch you are keeping track.\n"},{"id":"44807","messageId":"8c5c35580706120104m7c3e2b2cifca513f2dda50d23@mail.gmail.com","threadId":"8507","inReplyTo":"20070612072035.GA29385@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Lars Hjemli","fromEmail":"lh@elementstorage.no","sentAt":"2007-06-12T08:04:41Z","receivedAt":"2007-06-12T08:04:41Z","isPatch":false,"sender":{"key":"lh@elementstorage.no","avatar":null},"body":"On 6/12/07, Eric Wong wrote:\n> If dcommit detects a merge commit when doing rev-list When looking at\n> commit objects, is it safe to assume that the first parent is always the\n> \"mainline\" and that parents after it are the ones to merge from?\n>\n> So if I saw:\n>\n> commit $X\n> parent $A\n> parent $B\n>\n> I'd basically do:\n> reset --hard $A\n> merge --squash $B\n>\n> And resulting in $C which would have the same tree as $X,\n> then, when dcommit-ting, $D would be created with two parents:\n> $D~1 (svn), $B (git), but not $A\n>\n> Rewritten history:\n> $A => $D~1\n> $X => $D (HEAD revision in SVN)\n>\n> $X and $A are now discarded and gc-able.\n>\n>\n> Of course, since I already have the result of \"merge --squash $B\" in $X,\n> I could just rewrite $X with a single parent (call it $X'), dcommit, and\n> then give $D ($D~1 and $B) as parents. Avoiding the nastiness of\n> set-tree\n>\n\nWould it be possible to keep the 'local commit' $X and change the\nmapping in .rev_db to point at $X instead of $D? This would of course\nrequire a matching TREE-ID + noMetadata=1. I've been tempted to try to\nimplement this, but my perl-skills are sadly non-existent.\n\nIf this is possible it would make my day-job interaction with svn a\nmuch more pleasant experience: push/pull between git repos would 'just\nwork' (without -f).\n\nAnd if \"follow left parent\" also works out, I (and our\n'releasemaster') can finally do all merging in git (without --squash)\nand preserve the DAG. Ahh, that would be great...\n\n--\nlarsh\n"},{"id":"44809","messageId":"20070612083910.GA28369@muzzle","threadId":"8507","inReplyTo":"7v1wghlj7j.fsf@assigned-by-dhcp.pobox.com","subject":"Re: git-svn set-tree bug","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-12T08:39:10Z","receivedAt":"2007-06-12T08:39:10Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > If dcommit detects a merge commit when doing rev-list When looking at\n> > commit objects, is it safe to assume that the first parent is always the\n> > \"mainline\" and that parents after it are the ones to merge from?\n> >\n> > So if I saw:\n> >\n> > commit $X\n> > parent $A\n> > parent $B\n> >\n> > I'd basically do:\n> > reset --hard $A\n> > merge --squash $B\n> >\n> > And resulting in $C which would have the same tree as $X,\n> > then, when dcommit-ting, $D would be created with two parents:\n> > $D~1 (svn), $B (git), but not $A\n> \n> I am not sure what you mean by \"mainline\", but I assume that you\n> mean \"SVN is the main and we are tracking it while taking\n> advantage of more efficient and merge-capable git in guerrilla\n> fashion\". Because the tip of the current branch is what the\n> user is pushing back to SVN via dcommit, I would say it is safe\n> to assume that the first parent of such a merge is the line that\n> corresponds to the SVN branch you are keeping track.\n\nYes, \"mainline\" meaning the history that would be committed to SVN if\nhistory were linear.\n\nI've gotten the following patch working for Joakim's second test script\n(with dcommit before merge). However, without the dcommit before merge\nin the first test script, git-svn has trouble figuring out which history\nto follow. It'll take more work to figure out what to do in this\nsituation, and how to deal with more complex history...\n\nSubject: git-svn: Allow dcommit to handle certain single-parent merge commits\n\nThis only works if a merge is the first commit to be committed\nin a chain of commits.\n---\n git-svn.perl | 3 +++\n 1 files changed, 3 insertions(+), 0 deletions(-)\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 0ae8d70..6b3e021 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -403,6 +403,9 @@ sub cmd_dcommit {\n \t\t\t svn_path => '');\n \t\t\tif (!SVN::Git::Editor->new(\\%ed_opts)->apply_diff) {\n \t\t\t\tprint \"No changes\\n$d~1 == $d\\n\";\n+\t\t\t} elsif (my $merge_parent = verify_ref(\"$d^2\")) {\n+\t\t\t\t$gs->{inject_parents}->{$last_rev} =\n+\t\t\t\t $merge_parent;\n \t\t\t}\n \t\t}\n \t}\n-- \nEric Wong\n"},{"id":"44812","messageId":"1181640065.30670.200.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"20070612083910.GA28369@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-12T09:21:05Z","receivedAt":"2007-06-12T09:21:05Z","isPatch":false,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Tue, 2007-06-12 at 01:39 -0700, Eric Wong wrote:\n> Junio C Hamano wrote:\n> > Eric Wong writes:\n> > \n> > > If dcommit detects a merge commit when doing rev-list When looking at\n> > > commit objects, is it safe to assume that the first parent is always the\n> > > \"mainline\" and that parents after it are the ones to merge from?\n> > >\n> > > So if I saw:\n> > >\n> > > commit $X\n> > > parent $A\n> > > parent $B\n> > >\n> > > I'd basically do:\n> > > reset --hard $A\n> > > merge --squash $B\n> > >\n> > > And resulting in $C which would have the same tree as $X,\n> > > then, when dcommit-ting, $D would be created with two parents:\n> > > $D~1 (svn), $B (git), but not $A\n> > \n> > I am not sure what you mean by \"mainline\", but I assume that you\n> > mean \"SVN is the main and we are tracking it while taking\n> > advantage of more efficient and merge-capable git in guerrilla\n> > fashion\". Because the tip of the current branch is what the\n> > user is pushing back to SVN via dcommit, I would say it is safe\n> > to assume that the first parent of such a merge is the line that\n> > corresponds to the SVN branch you are keeping track.\n> \n> Yes, \"mainline\" meaning the history that would be committed to SVN if\n> history were linear.\n> \n> I've gotten the following patch working for Joakim's second test script\n> (with dcommit before merge). However, without the dcommit before merge\n> in the first test script, git-svn has trouble figuring out which history\n> to follow. It'll take more work to figure out what to do in this\n> situation, and how to deal with more complex history...\n> \n> Subject: git-svn: Allow dcommit to handle certain single-parent merge commits\n> \n> This only works if a merge is the first commit to be committed\n> in a chain of commits.\n[SNIP patch]\n\nNice!, now I get to keep the merge between the \"svn\" and the \"merge\" branch. The parents are swapped though:\nbefore last dcommit:\n Parent: b31cef1d3c6655441854ea8649359f0fc27f3e87 (friend)\n Parent: ed95b698c2e3336d387fed3763b213b3b90ebf4e (add some stuff)\n Branch: svn\n Follows: \n Precedes: \n\n Merge branch 'merge' into svn\n\nafter dcommit:\n\nParent: ed95b698c2e3336d387fed3763b213b3b90ebf4e (add some stuff)\nParent: b31cef1d3c6655441854ea8649359f0fc27f3e87 (friend)\nBranches: svn, remotes/trunk\nFollows: \nPrecedes: \n\n Merge branch 'merge' into svn\n \n \n git-svn-id: file:////usr/local/src/tst-git-svn/mysvnrepo/trunk@3 1585b9b0-b13 ....\n\n\nWill this also work for merging stuff from latest u-boot?\n\nI am doing dev. on my own u-boot branch and from time to time I want\nto merge in the latest from WD tree, then dcommit that merge. Later\nI want repeat that cycle.\n\nI have a SVN repo with my changes in it and I have grafted the beginning of\nthat tree into a clone of WDs tree.\n\n Jocke\n"},{"id":"44827","messageId":"466E8E50.8040809@midwinter.com","threadId":"8507","inReplyTo":"20070612083910.GA28369@muzzle","subject":"Re: git-svn set-tree bug","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-12T12:15:12Z","receivedAt":"2007-06-12T12:15:12Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Eric Wong wrote:\n> Yes, \"mainline\" meaning the history that would be committed to SVN if\n> history were linear.\n> \n\nI think the first parent is always the right one to follow. The only \ntime you won't hit a git-svn revision is if the user is trying to commit \na branch that is not originally derived from a git-svn branch, and IMO \nthat's something that git-svn is perfectly justified in refusing to do. \nAlso, the default \"git log\" output will follow the first parent; users \nwho run that are going to have a natural expectation that the subsequent \ncommits will be merged into the most recent git-svn revision as shown by \nthat tool.\n\n> This only works if a merge is the first commit to be committed\n> in a chain of commits.\n> \n\nAs for the more complex case of a chain of commits with a merge in the \nmiddle, IMO walking along the chain of first parents until you hit a \ngit-svn revision, then proceeding forward in time from there rewriting \nparents as you've described, is always going to be the right thing to \ndo. Or at least, all the use cases I can think of seem to be correctly \ncovered by that approach. Can someone come up with counterexamples?\n\nThis is great -- I'm looking forward to ditching my hackish merge script!\n\nAt the risk of getting ahead of myself, here's one more thought: in the \ncase where a merge's parents are all git-svn revisions -- that is, where \nthe user is using git to merge svn branches -- I wonder if it makes \nsense to optionally record that merge somehow in the commit comment on \nthe svn side. I think that could be made relatively human-readable so as \nnot to be too obnoxious for people browsing the svn history. That way \nsomeone pulling down a fresh git-svn clone of the svn repo could get a \nnice clean history with the merges represented properly in the git \nrevision history.\n\nThat's justifiable in another way too: the autogenerated comments on git \nmerge commits won't really make much sense over on the svn side, where \nmerges are thought of in terms of revision ranges. So replacing the \ngit-specific merge message with an svn-specific one doesn't seem \nunreasonable to me. (Again, optionally.) And in cases where the user has \nsupplied his own merge comment on the git side, annotating it with the \nadditional git-svn metadata seems reasonable to me. We are already fine \nwith the git-side comments having a line of git-svn metadata, after all.\n\nMost of the svn-side merge comments in my company's repo look like \neither \"svn merge -r12345:67890 mybranch\" (where the developer wants to \nmake the merge's inputs very explicit to avoid any confusion) or \"Merge \nrevisions 12345 through 67890 from mybranch\", occasionally surrounded by \nsome explanatory text. If git-svn replaced the canned git merge message \nwith a canned message like one of those, people wouldn't be able to tell \nI'd used git-svn instead of svn to do the merge.\n\n-Steve\n"},{"id":"44908","messageId":"20070613092328.GA30318@muzzle","threadId":"8507","inReplyTo":"20070612083910.GA28369@muzzle","subject":"[PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-13T09:23:28Z","receivedAt":"2007-06-13T09:23:28Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"dcommit will still rewrite the HEAD commit and the history of the first\nparents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n\nHowever, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\npreserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN\nwith dcommit. Commits written to SVN will still not have any merge\ninformation besides anything in the commit message.\n\nThanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\nfor explanations, feedback, examples and test case.\n\nSigned-off-by: Eric Wong \n---\n\n This is a better patch that replaces the previous one.\n\n Junio:\n This one is a big change and should probably sit in pu or next\n for a bit. Double-checking the logic in linearize_history()\n would be greatly appreciated, too.\n \n I don't think there are any regressions for the\n already-linear-history case besides slightly reduced performance for\n new calls to cat-file.\n\n Joakim/Steven:\n Any further testing and test cases would be appreciated. Be very\n careful with real-world repositories, and run dcommit with the\n '-n' flag before actually committing to verify the diffs are sane.\n\n Thanks\n\n git-svn.perl | 72 +++++++++++++++++++++++++++----\n t/t9114-git-svn-dcommit-merge.sh | 89 ++++++++++++++++++++++++++++++++++++++\n 2 files changed, 152 insertions(+), 9 deletions(-)\n create mode 100755 t/t9114-git-svn-dcommit-merge.sh\n\ndiff --git a/git-svn.perl b/git-svn.perl\nindex 0ae8d70..4290676 100755\n--- a/git-svn.perl\n+++ b/git-svn.perl\n@@ -372,16 +372,9 @@ sub cmd_dcommit {\n \t\tdie \"Unable to determine upstream SVN information from \",\n \t\t \"$head history\\n\";\n \t}\n-\tmy $c = $refs[-1];\n \tmy $last_rev;\n-\tforeach my $d (@refs) {\n-\t\tif (!verify_ref(\"$d~1\")) {\n-\t\t\tfatal \"Commit $d\\n\",\n-\t\t\t \"has no parent commit, and therefore \",\n-\t\t\t \"nothing to diff against.\\n\",\n-\t\t\t \"You should be working from a repository \",\n-\t\t\t \"originally created by git-svn\\n\";\n-\t\t}\n+\tmy ($linear_refs, $parents) = linearize_history($gs, \\@refs);\n+\tforeach my $d (@$linear_refs) {\n \t\tunless (defined $last_rev) {\n \t\t\t(undef, $last_rev, undef) = cmt_metadata(\"$d~1\");\n \t\t\tunless (defined $last_rev) {\n@@ -403,6 +396,9 @@ sub cmd_dcommit {\n \t\t\t svn_path => '');\n \t\t\tif (!SVN::Git::Editor->new(\\%ed_opts)->apply_diff) {\n \t\t\t\tprint \"No changes\\n$d~1 == $d\\n\";\n+\t\t\t} elsif ($parents->{$d} && @{$parents->{$d}}) {\n+\t\t\t\t$gs->{inject_parents_dcommit}->{$last_rev} =\n+\t\t\t\t $parents->{$d};\n \t\t\t}\n \t\t}\n \t}\n@@ -821,6 +817,59 @@ sub working_head_info {\n \t(undef, undef, undef, undef);\n }\n \n+sub read_commit_parents {\n+\tmy ($parents, $c) = @_;\n+\tmy ($fh, $ctx) = command_output_pipe(qw/cat-file commit/, $c);\n+\twhile (<$fh>) {\n+\t\tchomp;\n+\t\tlast if '';\n+\t\t/^parent ($sha1)/ or next;\n+\t\tpush @{$parents->{$c}}, $1;\n+\t}\n+\tclose $fh; # break the pipe\n+}\n+\n+sub linearize_history {\n+\tmy ($gs, $refs) = @_;\n+\tmy %parents;\n+\tforeach my $c (@$refs) {\n+\t\tread_commit_parents(\\%parents, $c);\n+\t}\n+\n+\tmy @linear_refs;\n+\tmy %skip = ();\n+\tmy $last_svn_commit = $gs->last_commit;\n+\tforeach my $c (reverse @$refs) {\n+\t\tnext if $c eq $last_svn_commit;\n+\t\tlast if $skip{$c};\n+\n+\t\tunshift @linear_refs, $c;\n+\t\t$skip{$c} = 1;\n+\n+\t\t# we only want the first parent to diff against for linear\n+\t\t# history, we save the rest to inject when we finalize the\n+\t\t# svn commit\n+\t\tmy $fp_a = verify_ref(\"$c~1\");\n+\t\tmy $fp_b = shift @{$parents{$c}} if $parents{$c};\n+\t\tif (!$fp_a || !$fp_b) {\n+\t\t\tdie \"Commit $c\\n\",\n+\t\t\t \"has no parent commit, and therefore \",\n+\t\t\t \"nothing to diff against.\\n\",\n+\t\t\t \"You should be working from a repository \",\n+\t\t\t \"originally created by git-svn\\n\";\n+\t\t}\n+\t\tif ($fp_a ne $fp_b) {\n+\t\t\tdie \"$c~1 = $fp_a, however parsing commit $c \",\n+\t\t\t \"revealed that:\\n$c~1 = $fp_b\\nBUG!\\n\";\n+\t\t}\n+\n+\t\tforeach my $p (@{$parents{$c}}) {\n+\t\t\t$skip{$p} = 1;\n+\t\t}\n+\t}\n+\t(\\@linear_refs, \\%parents);\n+}\n+\n package Git::SVN;\n use strict;\n use warnings;\n@@ -1541,6 +1590,11 @@ sub get_commit_parents {\n \tif (my $cur = ::verify_ref($self->refname.'^0')) {\n \t\tpush @tmp, $cur;\n \t}\n+\tif (my $ipd = $self->{inject_parents_dcommit}) {\n+\t\tif (my $commit = delete $ipd->{$log_entry->{revision}}) {\n+\t\t\tpush @tmp, @$commit;\n+\t\t}\n+\t}\n \tpush @tmp, $_ foreach (@{$log_entry->{parents}}, @tmp);\n \twhile (my $p = shift @tmp) {\n \t\tnext if $seen{$p};\ndiff --git a/t/t9114-git-svn-dcommit-merge.sh b/t/t9114-git-svn-dcommit-merge.sh\nnew file mode 100755\nindex 0000000..d6ca955\n--- /dev/null\n+++ b/t/t9114-git-svn-dcommit-merge.sh\n@@ -0,0 +1,89 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2007 Eric Wong\n+# Based on a script by Joakim Tjernlund \n+\n+test_description='git-svn dcommit handles merges'\n+\n+. ./lib-git-svn.sh\n+\n+big_text_block () {\n+cat << EOF\n+#\n+# (C) Copyright 2000 - 2005\n+# Wolfgang Denk, DENX Software Engineering, wd@denx.de.\n+#\n+# See file CREDITS for list of people who contributed to this\n+# project.\n+#\n+# This program is free software; you can redistribute it and/or\n+# modify it under the terms of the GNU General Public License as\n+# published by the Free Software Foundation; either version 2 of\n+# the License, or (at your option) any later version.\n+#\n+# This program is distributed in the hope that it will be useful,\n+# but WITHOUT ANY WARRANTY; without even the implied warranty of\n+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\tSee the\n+# GNU General Public License for more details.\n+#\n+# You should have received a copy of the GNU General Public License\n+# along with this program; if not, write to the Free Software\n+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,\n+# MA 02111-1307 USA\n+#\n+EOF\n+}\n+\n+test_expect_success 'setup svn repository' \"\n+\tsvn co $svnrepo mysvnwork &&\n+\tmkdir -p mysvnwork/trunk &&\n+\tcd mysvnwork &&\n+\t\tbig_text_block >> trunk/README &&\n+\t\tsvn add trunk &&\n+\t\tsvn ci -m 'first commit' trunk &&\n+\t\tcd ..\n+\t\"\n+\n+test_expect_success 'setup git mirror and merge' \"\n+\tgit svn init $svnrepo -t tags -T trunk -b branches &&\n+\tgit svn fetch &&\n+\tgit checkout --track -b svn remotes/trunk &&\n+\tgit checkout -b merge &&\n+\techo new file > new_file &&\n+\tgit add new_file &&\n+\tgit commit -a -m 'New file' &&\n+\techo hello >> README &&\n+\tgit commit -a -m 'hello' &&\n+\techo add some stuff >> new_file &&\n+\tgit commit -a -m 'add some stuff' &&\n+\tgit checkout svn &&\n+\tmv -f README tmp &&\n+\techo friend > README &&\n+\tcat tmp >> README &&\n+\tgit commit -a -m 'friend' &&\n+\tgit pull . merge\n+\t\"\n+\n+test_debug 'gitk --all & sleep 1'\n+\n+test_expect_success 'verify pre-merge ancestry' \"\n+\ttest x\\`git rev-parse --verify refs/heads/svn^2\\` = \\\n+\t x\\`git rev-parse --verify refs/heads/merge\\` &&\n+\tgit cat-file commit refs/heads/svn^ | grep '^friend$'\n+\t\"\n+\n+test_expect_success 'git svn dcommit merges' \"\n+\tgit svn dcommit\n+\t\"\n+\n+test_debug 'gitk --all & sleep 1'\n+\n+test_expect_success 'verify post-merge ancestry' \"\n+\ttest x\\`git rev-parse --verify refs/heads/svn\\` = \\\n+\t x\\`git rev-parse --verify refs/remotes/trunk \\` &&\n+\ttest x\\`git rev-parse --verify refs/heads/svn^2\\` = \\\n+\t x\\`git rev-parse --verify refs/heads/merge\\` &&\n+\tgit cat-file commit refs/heads/svn^ | grep '^friend$'\n+\t\"\n+\n+test_done\n-- \nEric Wong\n"},{"id":"44974","messageId":"1181754781.30670.323.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"20070613092328.GA30318@muzzle","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-13T17:13:01Z","receivedAt":"2007-06-13T17:13:01Z","isPatch":true,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:\n> dcommit will still rewrite the HEAD commit and the history of the first\n> parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n> \n> However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\n> preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN\n> with dcommit. Commits written to SVN will still not have any merge\n> information besides anything in the commit message.\n> \n> Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\n> for explanations, feedback, examples and test case.\n> \n> Signed-off-by: Eric Wong \n> ---\n> \n> This is a better patch that replaces the previous one.\n> \n> Junio:\n> This one is a big change and should probably sit in pu or next\n> for a bit. Double-checking the logic in linearize_history()\n> would be greatly appreciated, too.\n> \n> I don't think there are any regressions for the\n> already-linear-history case besides slightly reduced performance for\n> new calls to cat-file.\n> \n> Joakim/Steven:\n> Any further testing and test cases would be appreciated. Be very\n> careful with real-world repositories, and run dcommit with the\n> '-n' flag before actually committing to verify the diffs are sane.\n> \n> Thanks\n> \n\nDid a little testing and so far it looks good :)\n\nSidenote:\nDoing this \n git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo\n git-svn fetch --quiet\nmakes git svn fetch stop for rather long periods in do_update:\n Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2\n Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n Following parent with do_update\n Successfully followed parent\n\nIs it possible to speed up do_update?\n\n\nLastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,\ncan I attach the svn tree to git u-boot tree without using a graft?\n\nI want to be able to recreate my own git repo by cloning the orginal u-boot\nrepo and the svn repo.\n\n Jocke\n"},{"id":"45017","messageId":"1181776659.30670.340.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"1181754781.30670.323.camel@gentoo-jocke.transmode.se","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-13T23:17:39Z","receivedAt":"2007-06-13T23:17:39Z","isPatch":true,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"On Wed, 2007-06-13 at 19:13 +0200, Joakim Tjernlund wrote:\n> On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:\n> > dcommit will still rewrite the HEAD commit and the history of the first\n> > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n> > \n> > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\n> > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN\n> > with dcommit. Commits written to SVN will still not have any merge\n> > information besides anything in the commit message.\n> > \n> > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\n> > for explanations, feedback, examples and test case.\n> > \n> > Signed-off-by: Eric Wong \n> > ---\n> > \n> > This is a better patch that replaces the previous one.\n> > \n> > Junio:\n> > This one is a big change and should probably sit in pu or next\n> > for a bit. Double-checking the logic in linearize_history()\n> > would be greatly appreciated, too.\n> > \n> > I don't think there are any regressions for the\n> > already-linear-history case besides slightly reduced performance for\n> > new calls to cat-file.\n> > \n> > Joakim/Steven:\n> > Any further testing and test cases would be appreciated. Be very\n> > careful with real-world repositories, and run dcommit with the\n> > '-n' flag before actually committing to verify the diffs are sane.\n> > \n> > Thanks\n> > \n> \n> Did a little testing and so far it looks good :)\n> \n> Sidenote:\n> Doing this \n> git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo\n> git-svn fetch --quiet\n> makes git svn fetch stop for rather long periods in do_update:\n> Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2\n> Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n> Following parent with do_update\n> Successfully followed parent\n> \n> Is it possible to speed up do_update?\n> \n> \n> Lastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,\n> can I attach the svn tree to git u-boot tree without using a graft?\n> \n> I want to be able to recreate my own git repo by cloning the orginal u-boot\n> repo and the svn repo.\n> \n> Jocke\n\nTried using --no-metadata(git svn clone --no-metadata) in my little test\nscript I sent earlier and got\n \"Unable to determine upstream SVN information from HEAD history\"\nwhen dcommiting, -i trunk didn't help either.\n\nIt is not entierly clear to me what --no-metadata means to me.\nDoes git-svn still rewrite commits?\nI can't rebuild rev_db file, if lost, but I guess I could still\ndo a new git-svn clone and restore my repo? I guess I lose something\nif I do that but what?\nAlso don't really understand why git-svn log doesn't work, can't it get\nthat info from the svn repo?\n\n Jocke\n"},{"id":"45043","messageId":"4670E0A2.9060103@midwinter.com","threadId":"8507","inReplyTo":"20070613092328.GA30318@muzzle","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2007-06-14T06:30:58Z","receivedAt":"2007-06-14T06:30:58Z","isPatch":true,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Eric Wong wrote:\n> Joakim/Steven:\n> Any further testing and test cases would be appreciated. Be very\n> careful with real-world repositories, and run dcommit with the\n> '-n' flag before actually committing to verify the diffs are sane.\n> \n\nI poked at this some tonight with an eye toward the use case of using \ngit to merge svn branches. I ran into one inconvenience and one bug. \nI'll try playing with the \"use lots of git branches to develop on one \nsvn branch\" use case some too, but for now, here are the notes I took, \nalong with the commands if anyone wants to reproduce what I did. \nHopefully this won't be too annoying to read. The bug is near the bottom.\n\nsvn repo with a trunk and a branch, each with changes (no conflicts at \nfirst, keep it simple to start)\n\n$ svnadmin create svnrepo\n$ svn co file://`pwd`/svnrepo svnclient\n$ cd svnclient\n$ mkdir trunk tags branches\n$ echo test file number 1 > trunk/testfile1\n$ echo test file number 2 > trunk/testfile2\n$ svn add *\n$ svn commit -m \"initial commit\"\n$ echo trunk change 1 >> trunk/testfile1\n$ svn commit -m \"trunk change 1\"\n$ echo trunk change 2 >> trunk/testfile2\n$ svn commit -m \"trunk change 2\"\n$ svn cp trunk branches/mybranch\n$ svn commit -m \"make a branch\"\n$ echo trunk change 3 >> trunk/testfile1\n$ svn commit -m \"post-branch change in trunk\"\n$ echo branch change 1 >> branches/mybranch/testfile2\n$ svn commit -m \"change in branch\"\n\ngit-svn clone of this dinky repo\n\n$ cd ..\n$ git-svn clone --trunk=trunk --branches=branches --tags=tags \nfile://`pwd`/svnrepo gitclone\n$ cd gitclone\n\nTry to merge trunk change into branch using git\n\n$ git reset --hard mybranch\n$ git merge trunk\n\nConflicts! what's going on?\n\n$ gitk --all\n\nAha, looks like git-svn guessed wrong about where I made the branch; it \nthinks the branch comes from the initial rev. Easy enough to hack \naround, but might be nice to be able to do this using git-svn's history \nrewriting rather than a grafts file.\n\n$ echo `git-svn find-rev r4` `git-svn find-rev r3 trunk` > .git/info/grafts\n$ git reset --hard mybranch\n$ git merge trunk\n\nNo conflicts now. Let's see what git-svn thinks it should do\n\n$ git-svn dcommit -n\n\nLooks like the right diff\n\n$ git-svn dcommit\n\nRefresh gitk display. Looks good, the new revision is a merge with the \nright parents. Let's check it out in svn land\n\n$ cd ../svnclient\n$ svn up\n$ cat branches/mybranch/testfile1\n\nYep, the trunk change is there, nice! Now for a couple more revs with a \nconflict.\n\n$ echo post-merge trunk change >> trunk/testfile1\n$ svn commit -m \"trunk change after merge\"\n$ echo post-merge conflicting change >> trunk/testfile2\n$ svn commit -m \"trunk change with conflict\"\n$ cd ../gitclone\n$ git-svn fetch\n$ git merge -m \"change with conflict\" trunk\n\nConflict, as expected\n\n$ vi testfile2\n$ git add testfile2\n$ git commit\n$ git-svn dcommit\nTransaction is out of date: Out of date: '/trunk/testfile1' in \ntransaction '9-1' at /Users/koreth/git/git-svn line 398\n\nHmm, this merge was in mybranch, not in trunk\n\n$ git log --first-parent\n\nYes, the most recent commit with a git-svn-id line has a mybranch URL. \nSo why is it complaining about a trunk file being out of date?\n\nMy experimentation pretty much ended there (I tried a few things to \nclear the error up, but none of them helped.)\n\nThis machine is an OS X laptop. Subversion is 1.4.3 (r23084) from \nMacPorts. I used the git-svn from the \"pu\" branch since it had this \npatch and all the recent fixes.\n\nLet me know if you need more details. Hope this is helpful.\n\n-Steve\n"},{"id":"45413","messageId":"20070620065600.GA25010@muzzle","threadId":"8507","inReplyTo":"1181754781.30670.323.camel@gentoo-jocke.transmode.se","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-20T06:56:00Z","receivedAt":"2007-06-20T06:56:00Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Joakim Tjernlund wrote:\n> On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:\n> > dcommit will still rewrite the HEAD commit and the history of the first\n> > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n> > \n> > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\n> > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN\n> > with dcommit. Commits written to SVN will still not have any merge\n> > information besides anything in the commit message.\n> > \n> > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\n> > for explanations, feedback, examples and test case.\n> > \n> > Signed-off-by: Eric Wong \n> > ---\n> > \n> > This is a better patch that replaces the previous one.\n> > \n> > Junio:\n> > This one is a big change and should probably sit in pu or next\n> > for a bit. Double-checking the logic in linearize_history()\n> > would be greatly appreciated, too.\n> > \n> > I don't think there are any regressions for the\n> > already-linear-history case besides slightly reduced performance for\n> > new calls to cat-file.\n> > \n> > Joakim/Steven:\n> > Any further testing and test cases would be appreciated. Be very\n> > careful with real-world repositories, and run dcommit with the\n> > '-n' flag before actually committing to verify the diffs are sane.\n> > \n> > Thanks\n> > \n> \n> Did a little testing and so far it looks good :)\n> \n> Sidenote:\n> Doing this \n> git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo\n> git-svn fetch --quiet\n> makes git svn fetch stop for rather long periods in do_update:\n> Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2\n> Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n> Following parent with do_update\n> Successfully followed parent\n> \n> Is it possible to speed up do_update?\n\nUse a do_switch()-enabled SVN to avoid do_update(). do_update will\nredownload everything. I have patched 1.4.3 debian packages with source\nand a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to\nhave fixed the bindings, but 1.4.3 claimed the same thing, too...\nConfirmation of it working in SVN 1.4.4 would be nice.\n\n> Lastly, when adding the above u-boot svn repo into a fresh u-boot\n> clone from WD, can I attach the svn tree to git u-boot tree without\n> using a graft?\n\nNot with the current version. The 1.5.0 (or previous, I forget) allowed\nforced-parenting with: \"git-svn fetch =\" but I figured\nnobody was using it, and it would be difficult to get working since\nfetch can now works on multiple trees and the same revision numbers can\nappear in multiple trees.\n\n> I want to be able to recreate my own git repo by cloning the orginal\n> u-boot repo and the svn repo.\n\n-- \nEric Wong\n"},{"id":"45415","messageId":"20070620070442.GB25010@muzzle","threadId":"8507","inReplyTo":"1181776659.30670.340.camel@gentoo-jocke.transmode.se","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-06-20T07:04:42Z","receivedAt":"2007-06-20T07:04:42Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Joakim Tjernlund wrote:\n> On Wed, 2007-06-13 at 19:13 +0200, Joakim Tjernlund wrote:\n> > On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:\n> > > dcommit will still rewrite the HEAD commit and the history of the first\n> > > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n> > > \n> > > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\n> > > preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN\n> > > with dcommit. Commits written to SVN will still not have any merge\n> > > information besides anything in the commit message.\n> > > \n> > > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\n> > > for explanations, feedback, examples and test case.\n> > > \n> > > Signed-off-by: Eric Wong \n> > > ---\n> > > \n> > > This is a better patch that replaces the previous one.\n> > > \n> > > Junio:\n> > > This one is a big change and should probably sit in pu or next\n> > > for a bit. Double-checking the logic in linearize_history()\n> > > would be greatly appreciated, too.\n> > > \n> > > I don't think there are any regressions for the\n> > > already-linear-history case besides slightly reduced performance for\n> > > new calls to cat-file.\n> > > \n> > > Joakim/Steven:\n> > > Any further testing and test cases would be appreciated. Be very\n> > > careful with real-world repositories, and run dcommit with the\n> > > '-n' flag before actually committing to verify the diffs are sane.\n> > > \n> > > Thanks\n> > > \n> > \n> > Did a little testing and so far it looks good :)\n> > \n> > Sidenote:\n> > Doing this \n> > git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo\n> > git-svn fetch --quiet\n> > makes git svn fetch stop for rather long periods in do_update:\n> > Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2\n> > Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n> > Following parent with do_update\n> > Successfully followed parent\n> > \n> > Is it possible to speed up do_update?\n> > \n> > \n> > Lastly, when adding the above u-boot svn repo into a fresh u-boot clone from WD,\n> > can I attach the svn tree to git u-boot tree without using a graft?\n> > \n> > I want to be able to recreate my own git repo by cloning the orginal u-boot\n> > repo and the svn repo.\n> > \n> > Jocke\n> \n> Tried using --no-metadata(git svn clone --no-metadata) in my little test\n> script I sent earlier and got\n> \"Unable to determine upstream SVN information from HEAD history\"\n> when dcommiting, -i trunk didn't help either.\n> \n> It is not entierly clear to me what --no-metadata means to me.\n> Does git-svn still rewrite commits?\n\n--no-metadata is really only useful for people doing one-shot imports\nand abandoning SVN. It leaves out the git-svn-id: lines at the bottom\nof commit messages, but still sets the committer/author names/email/date\nto what is in the SVN repository.\n\n> I can't rebuild rev_db file, if lost, but I guess I could still\n> do a new git-svn clone and restore my repo? I guess I lose something\n> if I do that but what?\n\nIf you lose your rev_db file with no-metadata, you'll have to redo the\ngit-svn clone\n\n> Also don't really understand why git-svn log doesn't work, can't it get\n> that info from the svn repo?\n\nGetting git-svn log working with --no-metadata would require radically\ndifferent code. dcommit would be very different, too. So yes, they\ndon't work because I'm lazy.\n\n-- \nEric Wong\n"},{"id":"45515","messageId":"042701c7b424$d31bdf30$0e67a8c0@Jocke","threadId":"8507","inReplyTo":"20070620065600.GA25010@muzzle","subject":"RE: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-21T16:54:25Z","receivedAt":"2007-06-21T16:54:25Z","isPatch":true,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":" \n\n> -----Original Message-----\n> From: Eric Wong [mailto:normalperson@yhbt.net] \n> Sent: den 20 juni 2007 08:56\n> To: Joakim Tjernlund\n> Cc: Junio C Hamano; Steven Grimm; git@vger.kernel.org\n> Subject: Re: [PATCH] git-svn: allow dcommit to retain local \n> merge information\n> \n> Joakim Tjernlund wrote:\n> > On Wed, 2007-06-13 at 02:23 -0700, Eric Wong wrote:\n> > > dcommit will still rewrite the HEAD commit and the \n> history of the first\n> > > parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.\n> > > \n> > > However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be\n> > > preserved when the new HEAD and HEAD~[0-9]+ commits are \n> rewritten to SVN\n> > > with dcommit. Commits written to SVN will still not have \n> any merge\n> > > information besides anything in the commit message.\n> > > \n> > > Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm\n> > > for explanations, feedback, examples and test case.\n> > > \n> > > Signed-off-by: Eric Wong \n> > > ---\n> > > \n> > > This is a better patch that replaces the previous one.\n> > > \n> > > Junio:\n> > > This one is a big change and should probably sit in pu or next\n> > > for a bit. Double-checking the logic in linearize_history()\n> > > would be greatly appreciated, too.\n> > > \n> > > I don't think there are any regressions for the\n> > > already-linear-history case besides slightly reduced \n> performance for\n> > > new calls to cat-file.\n> > > \n> > > Joakim/Steven:\n> > > Any further testing and test cases would be \n> appreciated. Be very\n> > > careful with real-world repositories, and run dcommit with the\n> > > '-n' flag before actually committing to verify the \n> diffs are sane.\n> > > \n> > > Thanks\n> > > \n> > \n> > Did a little testing and so far it looks good :)\n> > \n> > Sidenote:\n> > Doing this \n> > git-svn init -t tags -T trunk -b branches \n> file:///usr/local/src/tst-git-svn/svn-uboot-repo\n> > git-svn fetch --quiet\n> > makes git svn fetch stop for rather long periods in do_update:\n> > Found possible branch point: \n> file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => \n> file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-ubo\n> ot-1.1.4, 2\n> > Found branch parent: (tags/snap-uboot-1.1.4) \n> 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n> > Following parent with do_update\n> > Successfully followed parent\n> > \n> > Is it possible to speed up do_update?\n> \n> Use a do_switch()-enabled SVN to avoid do_update(). do_update will\n> redownload everything. I have patched 1.4.3 debian packages \n> with source\n> and a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to\n> have fixed the bindings, but 1.4.3 claimed the same thing, too...\n> Confirmation of it working in SVN 1.4.4 would be nice.\n\nConfirmed as requested, I installed 1.4.4(Gentoo) an ran the\nsame test case. Now I see \"Following parent with do_switch\"\ninstead and it is almost instant. It felt though that\ngit-svn was somewhat slower importing large diffs.\n\n Jocke\n\n> \n> > Lastly, when adding the above u-boot svn repo into a fresh u-boot\n> > clone from WD, can I attach the svn tree to git u-boot tree without\n> > using a graft?\n> \n> Not with the current version. The 1.5.0 (or previous, I \n> forget) allowed\n> forced-parenting with: \"git-svn fetch =\" but I figured\n> nobody was using it, and it would be difficult to get working since\n> fetch can now works on multiple trees and the same revision \n> numbers can\n> appear in multiple trees.\n\nIf you reconsider this, please let me know.\n\n Jocke\n"},{"id":"45564","messageId":"006001c7b4c4$32e38630$0e67a8c0@Jocke","threadId":"8507","inReplyTo":"4670E0A2.9060103@midwinter.com","subject":"RE: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-06-22T11:55:15Z","receivedAt":"2007-06-22T11:55:15Z","isPatch":true,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"> -----Original Message-----\n> From: Steven Grimm [mailto:koreth@midwinter.com] \n> Sent: den 14 juni 2007 08:31\n> To: Eric Wong\n> Cc: Junio C Hamano; Joakim Tjernlund; git@vger.kernel.org\n> Subject: Re: [PATCH] git-svn: allow dcommit to retain local \n> merge information\n> \n> Eric Wong wrote:\n> > Joakim/Steven:\n> > Any further testing and test cases would be appreciated. Be very\n> > careful with real-world repositories, and run dcommit with the\n> > '-n' flag before actually committing to verify the diffs \n> are sane.\n> > \n> \n> I poked at this some tonight with an eye toward the use case of using \n> git to merge svn branches. I ran into one inconvenience and one bug. \n> I'll try playing with the \"use lots of git branches to develop on one \n> svn branch\" use case some too, but for now, here are the \n> notes I took, \n> along with the commands if anyone wants to reproduce what I did. \n> Hopefully this won't be too annoying to read. The bug is near \n> the bottom.\n> \n> svn repo with a trunk and a branch, each with changes (no \n> conflicts at \n> first, keep it simple to start)\n> \n> $ svnadmin create svnrepo\n> $ svn co file://`pwd`/svnrepo svnclient\n> $ cd svnclient\n> $ mkdir trunk tags branches\n> $ echo test file number 1 > trunk/testfile1\n> $ echo test file number 2 > trunk/testfile2\n> $ svn add *\n> $ svn commit -m \"initial commit\"\n> $ echo trunk change 1 >> trunk/testfile1\n> $ svn commit -m \"trunk change 1\"\n> $ echo trunk change 2 >> trunk/testfile2\n> $ svn commit -m \"trunk change 2\"\n> $ svn cp trunk branches/mybranch\n> $ svn commit -m \"make a branch\"\n> $ echo trunk change 3 >> trunk/testfile1\n> $ svn commit -m \"post-branch change in trunk\"\n> $ echo branch change 1 >> branches/mybranch/testfile2\n> $ svn commit -m \"change in branch\"\n> \n> git-svn clone of this dinky repo\n> \n> $ cd ..\n> $ git-svn clone --trunk=trunk --branches=branches --tags=tags \n> file://`pwd`/svnrepo gitclone\n> $ cd gitclone\n> \n> Try to merge trunk change into branch using git\n> \n> $ git reset --hard mybranch\n> $ git merge trunk\n> \n> Conflicts! what's going on?\n> \n> $ gitk --all\n> \n> Aha, looks like git-svn guessed wrong about where I made the \n> branch; it \n> thinks the branch comes from the initial rev. Easy enough to hack \n> around, but might be nice to be able to do this using \n> git-svn's history \n> rewriting rather than a grafts file.\n\nYes, that would be nice indeed.\n\n> \n> $ echo `git-svn find-rev r4` `git-svn find-rev r3 trunk` > \n> .git/info/grafts\n> $ git reset --hard mybranch\n> $ git merge trunk\n> \n> No conflicts now. Let's see what git-svn thinks it should do\n> \n> $ git-svn dcommit -n\n> \n> Looks like the right diff\n> \n> $ git-svn dcommit\n> \n> Refresh gitk display. Looks good, the new revision is a merge \n> with the \n> right parents. Let's check it out in svn land\n> \n> $ cd ../svnclient\n> $ svn up\n> $ cat branches/mybranch/testfile1\n> \n> Yep, the trunk change is there, nice! Now for a couple more \n> revs with a \n> conflict.\n> \n> $ echo post-merge trunk change >> trunk/testfile1\n> $ svn commit -m \"trunk change after merge\"\n> $ echo post-merge conflicting change >> trunk/testfile2\n> $ svn commit -m \"trunk change with conflict\"\n> $ cd ../gitclone\n> $ git-svn fetch\n> $ git merge -m \"change with conflict\" trunk\n> \n> Conflict, as expected\n> \n> $ vi testfile2\n> $ git add testfile2\n> $ git commit\n> $ git-svn dcommit\n> Transaction is out of date: Out of date: '/trunk/testfile1' in \n> transaction '9-1' at /Users/koreth/git/git-svn line 398\n\nMaybe this can help?\nhttp://svn.haxx.se/subusers/archive-2005-02/0096.shtml\nhttp://subclipse.tigris.org/faq.html#out-of-date\n\n> \n> Hmm, this merge was in mybranch, not in trunk\n> \n> $ git log --first-parent\n> \n> Yes, the most recent commit with a git-svn-id line has a \n> mybranch URL. \n> So why is it complaining about a trunk file being out of date?\n> \n> My experimentation pretty much ended there (I tried a few things to \n> clear the error up, but none of them helped.)\n> \n> This machine is an OS X laptop. Subversion is 1.4.3 (r23084) from \n> MacPorts. I used the git-svn from the \"pu\" branch since it had this \n> patch and all the recent fixes.\n> \n> Let me know if you need more details. Hope this is helpful.\n> \n> -Steve\n> \n> \n"},{"id":"46165","messageId":"1183295384.20673.116.camel@gentoo-jocke.transmode.se","threadId":"8507","inReplyTo":"20070620065600.GA25010@muzzle","subject":"Re: [PATCH] git-svn: allow dcommit to retain local merge information","fromName":"Joakim Tjernlund","fromEmail":"joakim.tjernlund@transmode.se","sentAt":"2007-07-01T13:09:44Z","receivedAt":"2007-07-01T13:09:44Z","isPatch":true,"sender":{"key":"joakim.tjernlund@transmode.se","avatar":null},"body":"\n> > Sidenote:\n> > Doing this \n> > git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo\n> > git-svn fetch --quiet\n> > makes git svn fetch stop for rather long periods in do_update:\n> > Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2\n> > Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8\n> > Following parent with do_update\n> > Successfully followed parent\n> > \n> > Is it possible to speed up do_update?\n> \n> Use a do_switch()-enabled SVN to avoid do_update(). do_update will\n> redownload everything. I have patched 1.4.3 debian packages with source\n> and a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to\n> have fixed the bindings, but 1.4.3 claimed the same thing, too...\n> Confirmation of it working in SVN 1.4.4 would be nice.\n\nI upgraded to svn 1.4.4 and it seemed to work OK, but then i noticed\nsome problems, \n git clone -t tags -T trunk -b branches svn+ssh://devsrv/svn/TM-uboot\nfailed(error msg was something with \"Malformed data ...\")\n\nI decided to go back to 1.4.3 with you patch, switch-editor-perl.diff\napplied. Now the error was gone, but the clone operation did use\ndo_update insted of do_switch. Did I miss someting?\n\n Jocke\n"}]}