Thanks for your answer, Peter! On Tue, Mar 03, 2009 at 02:35:28PM -0500, Peter Harris wrote: > On Tue, Mar 3, 2009 at 1:51 PM, Josef Wolf wrote: > > # work on clones, pull work into git-svn-repos when we're done > > # > > for clone in 1 2 3; do > > ( > > cd clone$clone > > git pull --rebase > > for commit in 1 2 3; do > > echo change $clone $commit >>test > > git commit -a -m "commit $clone $commit" > > done > > ) > > (cd git-svn-repos; git pull --rebase ../clone$clone) > > done > > Um. This has each clone basing their commits on the work of some other > clone. This line, specifically: > > > (cd git-svn-repos; git pull --rebase ../clone$clone) > > breaks the "git-svn-repos only ever pulls from subversion" model I > suggested elsewhere. I'd rather not let every clone talk to subversion for several reasons. One of them is that it is very inconvenient (e.g. the password has to be entered several times for every commit). After all, the whole point for having git-svn-repos is for the clone to avoid working directly against the subversion repos. If every clone works against subversion anyway, I can get rid of git-svn-repos as well. > Also, this line says "rebase my changes onto those of ../clone$clone", > which isn't what you want. It will end up rebasing svn commits that > the client didn't have on top of the client's commits, and will break > git-svn's index. Don't use --rebase here. Hmm, I must have misunderstood Michael, then. Wasn't he suggesting to rebase here? Here's the citation: |> (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'. | |Instead, use git pull --rebase here. You don't want merges in the branch |from which you dcommit. > > # Although we have resolved the conflict, spurious conflicts are > > # propagated to the clones > > ...and this is because you had clones all merge from each other (via > git-svn-repos) *before* the changes were in svn. Does that mean that the conflicts would disappear if I do git-svn-rebase + git-svn-dcommit after every pull from a clone? > Worse, since the git clients don't know that their work has been > rebased, they can wind up conflicting with themselves too. Which is > why I suggested "git svn dcommit" from each client, not from the > central repository. > > This can be made work if you do something more like (untested): > (cd git-svn-repos; git pull ../clone$clone topic-branch; > git svn dcommit) > (cd clone$clone; git checkout master; git pull; > have a human verify that changes to master are correct; > git branch -D topic-branch) > > instead of > > > (cd git-svn-repos; git pull --rebase ../clone$clone) > > ie. throw away each topic branch as you push it to git-svn-repos, and > take the changes that have gone through git-svn back via a pull of > master. > > But that starts to look to me like more work for each clone than "git > svn dcommit" - YMMV, of course. It might be more work. But at least, I have the impression that I understand this workflow. ;-) -- 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
