Re: Using git to bridge two svn repositories: a success story

From: Junio C Hamano <junkio@cox.net>
Date: Apr 20, 2007, 07:18 UTC
Message-ID: <7vk5w7344y.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <46283DC4.7070604@midwinter.com>

Steven Grimm <koreth@midwinter.com> writes:

Show 5 quoted lines

> ..., so here's a success
> story I can share for a change. I just used git to merge two separate
> svn repositories: the official repo for an open-source program and an
> internal repo with our locally-modified version of the same
> program.

Nice story.  Thanks for sharing.

Show 7 quoted lines

> Now, about those renames. The major change in structure was to rename
> the source directory from "server" in the official repository to "src"
> which our build system expects. So before I did any merges, I
> committed a revision where I did "git mv src server" (along with a
> couple other similar renames) so there'd be an explicit rename-only
> revision for git's rename detection to use to apply changes to the
> right files.

In the work you did in the story, your rename from server to src was indeed an atomic action YOU wanted to have, which was done to match the two tree structure. It was your project, not git, that did not want the name upstream uses. So it makes perfect sense to have that rename-only commit. But if you do it only because you think it would help later merges, don't.

I do not know who started this myth, but "rename only commit" does not help rename detection in merges AT ALL, as rename deteciton is not done step-by-step, but between ancestor and the tip of each branch.

A "rename-only commit" does help if you are following history with "git log -p -M", where rename detection logic compares trees stepwise. I think somebody confused this with the rename detection done by the merge machinery to start the myth. Please do not spread it any further.