Attached are two patches:
1. resubmission of the original patch with proper sign-off; and 2. patch with permissions fix (thanks to Alex Reisen for pointing out); A few points in defense of specification of merge graph in terms of SVN rev numbers.
a) This information is often directly available from svn log records. While there is no one agreed format of svn commit messages reflecting merge information, many projects adopted their own rules about that. So it is often possible to write a project-specific script which will automate the step of creating the graph in terms of SVN revs. Suggested merge graph format serves as an interface between such scripts and git-svnimport.
As there is no need to operate in terms of git commit ids, debugging of such script does not require any import operations.
b) Generic git tool which allows fine editing of merge lines in git repo is certainly a good thing to have, but it is more suitable for fine editing after the import completed, where only a small number of corrections is required. This tool is beyond the scope of this patch.
c) Different importers may have very different issues to deal with. The proposed patch for git-svnimport takes advantage of a notion of a changeset available in SVN. For example CVS does not have such a concept, so different means should be used there. See how options -m/-M of git-svnimport were carried over from CVS to SVN. This is likely to be the case with other importers.
Stas.
----- Original Message ---- From: Peter Baumann <waste.manager@gmx.de> To: Stas Maximov <smaximov@yahoo.com> Cc: git@vger.kernel.org; Junio C Hamano <gitster@pobox.com> Sent: Sunday, June 24, 2007 1:44:27 AM Subject: Re: [PATCH] git-svnimport: added explicit merge graph option -G
[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
