From: Josef Wolf Date: Fri, 01 May 2009 14:28:11 GMT Subject: Re: Trying to sync two svn repositories with git-svn (repost) Message-ID: <20090501142811.GI15420@raven.wolf.lan> In-Reply-To: <32541b130904301559w329bdd4bo6f2736a505b7235f@mail.gmail.com> On Thu, Apr 30, 2009 at 06:59:50PM -0400, Avery Pennarun wrote: > On Thu, Apr 30, 2009 at 6:28 PM, Josef Wolf wrote: > >  # cherry-pick from second-svn to first-svn > >  # > >  git svn checkout first-svn > >  git cherry-pick sha1-from-second-svn # repeat as needed > >  git checkout first-svn/trunk > >  git merge --no-ff first-svn > >  git diff first-svn/trunk first-svn >changes.diff > >  git svn dcommit > [...] > > But I am still somewhat confused: > > > >  git log -1 first-svn/trunk > > > > says "Merge branch first-svn into HEAD".  But this does not reflect > > what I've actually done: I've picked _from_ second-svn and committed > > that _to_ first-svn. > > The most recent commit to first-svn/trunk was "git merge --no-ff > first-svn", which creates the merge commit you're seeing here. (HEAD > == first-svn/trunk). So this sounds right to me. > > "git log -1 first-svn" would give you the first cherry-pick. But > remember, it's a completely different branch. I can see why this happens, but I still find it confusing. Maybe I should help with the -m option? > >> What you probably thought you should do, given that the existing > >> git-svn documentation says to do it, is more like this: > >> > >>    # WRONG > >>    git checkout first-svn > >>    git cherry-pick some stuff > >>    git merge [perhaps -s ours] second-svn/trunk > >>    git svn dcommit > > > > Almost... In addition, I was trying to "git svn rebase" before the > > dcommit > > 'git svn dcommit' implies 'git svn rebase' first anyway, so it's the same. > > > What would happen if somebody else creates a new commit just after I > > "git svn fetch" but before I dcommit?  Guess, svn will not accept this > > commit, because it is based on an outdated revision.  How would I > > get out from this situation? > > AFAIK, it will attempt to do "git svn rebase" first, and if that > succeeds, it will do the commit. > > In such a case, the rebase should be okay, because it's only changing > commits (in fact, just one commit: the merge commit) that don't exist > on any other branch. Thus it won't mangle any other merges. Yeah, that's the simple case. But what if the rebase don't succeed? > > Ummm, no.. I have _two_ branches: > > > >  first-svn:  contains the cherries that I picked from second-svn. This > >              branch looks the way first-svn/trunk should be > >  second-svn: contains the cherries that I picked from first-svn. This > >              looks the way second-svn/trunk should be > > Okay, if you want to end up with two different remote branches, it > makes sense to have two different local branches. Well, I _have_ two different remotes because I have two svn repositories. > > Don't I need to rebase at least one of them if I want to "merge" those > > two branches into a single one? > > I don't think so. If you merge them together, what do you *want* it > to look like? And what do you want to do with that branch afterwards? > It's hard for me to guess, but it seems unlikely that rebasing things > will get you there. Then I have to keep both local branches. But I still wonder why you suggested to go with _one_ local branch. > If what you want is "one central branch that currently looks like > first-svn/trunk or second-svn/trunk or maybe something else, but we'll > be merging future changes to first-svn and second-svn into it in the > future", then you would do: > > git checkout -b one-true-branch > ...make it look however you want... > # now mark it as up-to-date with svn, but don't change anything > git merge -s ours first-svn/trunk > git merge -s ours second-svn/trunk > > And then in the future, whenever first-svn/trunk or second-svn/trunk > change, you would do: > > git merge first-svn/trunk > git merge second-svn/trunk > > etc. I guess that might be interesting for the generic branch, where all the localizations are replaced by templates.