On Thu, Apr 30, 2009 at 06:59:50PM -0400, Avery Pennarun wrote: > On Thu, Apr 30, 2009 at 6:28 PM, Josef Wolf <jw@xxxxxxxxxxxxx> 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. -- 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