{"thread":{"id":"8701","subject":"Re: [PATCH] git-svnimport: added explicit merge graph option -G","startedAt":"2007-06-24T21:48:40Z","lastAt":"2007-06-24T22:17:05Z","messageCount":2,"participants":["Stas Maximov","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"45698","messageId":"49428.47661.qm@web43139.mail.sp1.yahoo.com","threadId":"8701","inReplyTo":null,"subject":"Re: [PATCH] git-svnimport: added explicit merge graph option -G","fromName":"Stas Maximov","fromEmail":"smaximov@yahoo.com","sentAt":"2007-06-24T21:48:40Z","receivedAt":"2007-06-24T21:48:40Z","isPatch":true,"sender":{"key":"smaximov@yahoo.com","avatar":null},"body":"Attached are two patches:\n\n1. resubmission of the original patch with proper sign-off; and \n2. patch with permissions fix (thanks to Alex Reisen for pointing out);\n \n \n A few points in defense of specification of merge graph in terms of SVN rev numbers.\n\na) 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.\n\nAs there is no need to operate in terms of git commit ids, debugging of such script does not require any import operations. \n\nb) 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.\n\nc) 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. \n\n\nStas.\n \n\n----- Original Message ----\nFrom: Peter Baumann \nTo: Stas Maximov \nCc: git@vger.kernel.org; Junio C Hamano \nSent: Sunday, June 24, 2007 1:44:27 AM\nSubject: Re: [PATCH] git-svnimport: added explicit merge graph option -G\n\n[exchanging To:/Cc: as Junio just forwarded the message from Stas]\n\nNot commenting on the patch per se, but wouldn't it make more\nsense to have such functionality in a history rewriting tool like\ne.g. git-branch-filter?\n\nI had an svn import (git-svn) where I wanted to give correct\nbranch/merge points, too, and so I manually created a grafts file\nannotating all the svn merges. Having such a thing as a _generic_ tool\nwhich operates on grafts would be much more usefull because you get one\nimplementation which could be used for each and every importer out\nthere. Sure, you have to transform the native revision specifieres into\nthe GIT commit id's if you only have e.g. \"merged r4711:4720 into trunk\",\nbut these functionality is much more common to have in importers\nthan whats implemented in the above mentioned patch.\n\nAnother bonus point of using the grafts mechanism you'll get for free is\nthat you could _look_ at the commit graph in gitk *before* doing the\noften expensive reimport of your project, so could be sure you haven't\nforgotten to mark a merge.\n\n-Peter Baumann\n\n\n"},{"id":"45699","messageId":"7vd4zlq9pa.fsf@assigned-by-dhcp.cox.net","threadId":"8701","inReplyTo":"49428.47661.qm@web43139.mail.sp1.yahoo.com","subject":"Re: [PATCH] git-svnimport: added explicit merge graph option -G","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-24T22:17:05Z","receivedAt":"2007-06-24T22:17:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stas Maximov writes:\n\n> Attached are two patches:\n>\n> 1. resubmission of the original patch with proper sign-off; and \n> 2. patch with permissions fix (thanks to Alex Reisen for pointing out);\n\nAs you are assuming that the original patch was rejected (by\nresending that as the first one here), I do not think these\nchanges should be in two separate commits. Please redo them as\na single patch.\n\nAlso please do not \"Attach\". When you have N patches to send,\nsend N e-mail messages, numbered from [PATCH 1/N] to [PATCH\nN/N], each with one patch in the message itself.\n\nPlease see Documentation/SubmittingPatches.\n"}]}