Eric Wong <normalperson@xxxxxxxx> writes: >> I could imagine that leaving git-svn alone and adding a hook to git-log >> would be more useful, though. > > NACK on modifying git-svn to support more changelog formats. Honestly, I am neutral about this one. I think it all depends on the motivation behind the desire to rewrite the log. If the project that was hosted in Subversion wants to switch (perhaps gradually) to git, _and_ if the project also wants to adopt a workflow that does not do the GNU style changelog in the commit log but use a one-line summary friendly format, then sanitizing the commit log while importing via git-svn would make sense. Even though filter-branch after conversion would be another possibility, that option is only available if you are converting away from Subversion, never to return. On the other extreme, if the Subversion side will always be the canonical one, _or_ if the project does not want to change its commit log format, then I think it makes perfect sense to limit the commit log munging to the absolute minimum (but even in such a case, the user can just run git-svn without activating the log munging option --- so I do not think it is such a big deal to add or reject an option like this). > A better idea would be to write a generic script that takes "git log", > "git svn log" or even plain "svn log" output and filters it > independently. That's an independent topic. If such a filter supports a feature like our shortlog command has, people whose history is still trapped in Subversion would benefit from it. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
