Subject: Re: [PATCH] git-svnimport: added explicit merge graph option -G

From: Peter Baumann <[email-masked]>
Date: Sun, 24 Jun 2007 10:44:27 +0200

On Sun, Jun 24, 2007 at 12:06:20AM -0700, Junio C Hamano wrote:
> From: Stas Maximov <[email-masked]>
> Date: Sat, 23 Jun 2007 09:06:30 -0700
> 
> Allows explicit merge graph information to be provided. Each line
> of merge graph file must contain a pair of SVN revision numbers
> separated by space. The first number is child (merged to) SVN rev
> number and the second is the parent (merged from) SVN rev number.
> Comments can be started with '#' and continue to the end of line.
> Empty and space-only lines are allowed and will be ignored.
> ---
> 
>  * Stas, please give a "Signed-off-by" line, and get in the
>    habit of always CC the list.
> 
>    I received a format-patch output as attachment from Stas.  As
>    I cannot comment on the patch in that format, I am making a
>    verbatim forward to the list.
> 
>    I'll comment on the patch separately when I am through it,
>    but would appreciate comments from people who were involved
>    in git-svnimport in the past, and still use it.
> 
>    "You should use git-svn instead" people can repeat that as
>    usual, but at the same time it might be worth realizing that
>    there are people who maintain git-svnimport being better for
>    one-short importing.
> 

[exchanging To:/Cc: as Junio just forwarded the message from Stas]

Not commenting on the patch per se, but wouldn't it make more
sense to have such functionality in a history rewriting tool like
e.g. git-branch-filter?

I had an svn import (git-svn) where I wanted to give correct
branch/merge points, too, and so I manually created a grafts file
annotating all the svn merges. Having such a thing as a _generic_ tool
which operates on grafts would be much more usefull because you get one
implementation which could be used for each and every importer out
there. Sure, you have to transform the native revision specifieres into
the GIT commit id's if you only have e.g. "merged r4711:4720 into trunk",
but these functionality is much more common to have in importers
than whats implemented in the above mentioned patch.

Another bonus point of using the grafts mechanism you'll get for free is
that you could _look_ at the commit graph in gitk *before* doing the
often expensive reimport of your project, so could be sure you haven't
forgotten to mark a merge.

-Peter Baumann