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

[Junio C Hamano <junkio@cox.net>]

Steven Grimm <koreth@midwinter.com> writes:

> ..., 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.

> 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.