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

On Sun, Jun 24, 2007 at 10:44:27AM +0200, Peter Baumann wrote:

On Sun, Jun 24, 2007 at 12:06:20AM -0700, Junio C Hamano wrote:

quoted

From: Stas Maximov <redacted>
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.

There was a message that git-filter-branch already could to this, which
I didn't know:

http://thread.gmane.org/gmane.comp.version-control.git/50736/focus=50872

-Peter