Josef Wolf venit, vidit, dixit 27.02.2009 23:05: > Thanks for your patience, Michael! > > On Fri, Feb 27, 2009 at 06:45:44PM +0100, Michael J Gruber wrote: >> Josef Wolf venit, vidit, dixit 27.02.2009 18:12: >>> On Wed, Feb 25, 2009 at 10:26:10AM +0100, Michael J Gruber wrote: >>>> Josef Wolf venit, vidit, dixit 24.02.2009 23:34: > > [ ... ] >>> (cd git-svn-repos; git pull ../clone1) >> Gives you 1-2-3-4 >> >>> (cd git-svn-repos; git svn rebase) >> Does nothing here (but is good practice) >> >>> (cd git-svn-repos; git svn dcommit) >> Creates 2-3-4 on the svn side. *Then rebases* your master, which creates >> 1-2'-3'-4' on master. Note that 2 is different from 2' (git-svn id). > > So the sha1 is not preserved when it goes through svn? No. Once your commits come back from svn through git-svn they have an additional line in the commit. Also, the commit time time will be different, and the author name might be depending on your name remapping. The patch-id (which only looks at the actual diff being introduced) should be the same. >>> (cd git-svn-repos; git pull ../clone1) # if this line is executed, >> That's the problem. This creates a merge after which you 1-2-3-4 and >> 1-2'-3'-4' plus the merge of 4 and 4'. > > --verbosity=on please ;-) No such option "--verbosity". ;) Uhm, I'm just not good at diagramms in ascii. You had 1-2-3-4 in git-svn-repo. 2, 3 and 4 were dcommit to svn and came back as 2', 3', 4', such that git-svn rebased your master branch in git-svn-repo and master looked like 1-2'-3'-4'. The primed version are the one with an additional git-svn-id line in the commit: different sha1 from the unprimed version, same patch-id. Now, if you say pull ../clone1, you fetch from there and merges FETCH_HEAD, i.e. the tip of ../clone1, which is 4. So you get 1-2'-3'-4'-o \ / 2 -3 -4 with o being the tip (HEAD) of master. And that is the problem, because no history is not linear in master, and the next git-svn dcommit won't know what to do. >> Instead, use git pull --rebase here. You don't want merges in the branch >> from which you dcommit. > > Yeah, "pull --rebase" seems to help a lot. So I've come up with the next > version of my workflow-test-script: > > ( > set -ex > > # create test directory > # > TESTDIR=`mktemp --tmpdir=. git-svn-hierarchy-test-XXXXXXXX` > rm -rf $TESTDIR > mkdir -p $TESTDIR > cd $TESTDIR > > SUBVERSION_REPOS=file://`pwd`/subversion-repos > > # create subversion repos with some history > # > svnadmin create subversion-repos > svn -m "create standard layout" mkdir \ > $SUBVERSION_REPOS/trunk \ > $SUBVERSION_REPOS/branches \ > $SUBVERSION_REPOS/tags > svn co $SUBVERSION_REPOS/trunk subversion-wc > echo change1 >>subversion-wc/test > svn add subversion-wc/test > svn ci -m "commit 0" subversion-wc > > # create git-svn-repos > # > git svn init --stdlayout $SUBVERSION_REPOS git-svn-repos > (cd git-svn-repos; git svn fetch) > > # create clones > # > git clone git-svn-repos clone1 > git clone git-svn-repos clone2 > git clone git-svn-repos clone3 > > # now go several times to every clone, do some work on it, and sync > # the results > # > for cycle in 1 2 3; do > for clone in 1 2 3; do > for commit in 1 2 3; do > ( > cd clone$clone > git pull --rebase > echo change $clone $commit >>test > git commit -a -m "commit $clone $commit" > ) > done > (cd git-svn-repos; git pull --rebase ../clone$clone) > (cd git-svn-repos; git svn rebase) > (cd git-svn-repos; git svn dcommit) > done > done > ) > > At least, this seems to not creating collisions any more. But I'm still > not sure I fully understand what's going on here. Guess, I'll have to > get into the learning-by-doing mode :) Yes, be sure to check the DAG (the graph of commits which you produced) using something like gitk or git log --graph with the "--all" argument so that you see all branches! >> Borrowing from some other vcs: >> >> Repeat the soothing mantra: a merge is no merge is no merge - it it's in >> svn ;) > > Huh? I meant "if it's", sorry for the typo. If you don't get the plug don't worry (or look up hg) ;) >>> Obviously, I'm doing something wrong. But I can't figure what. Any hints? >> I guess when we said integrated we should have said rebase. Haven't we? > > You like to talk in riddles? Aren't you? No, I'm not ;) Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
