On 2008-06-12 22:41:46 -0700, Junio C Hamano wrote: > Avery Pennarun <apenwarr@xxxxxxxxx> writes: > > > In git, all commits end in exactly one newline character. In svn, > > commits end in zero or more newlines. Thus, when importing commits > > from svn into git, git-svn always appends two extra newlines to > > ensure that the git-svn-id: line is separated from the main commit > > message by at least one blank line. > > > > Combined with the terminating newline that's always present in svn > > commits produced by git, you usually end up with two blank lines > > instead of one between the commit message and git-svn-id: line, > > which is undesirable. > > > > Instead, let's remove all trailing whitespace from the git commit > > on the way through to svn. > > Perl part of the code looks fine but I am unsure if we like the > ramifications of this patch on existing git-svn managed > repositories. Doesn't this change the commit object name on our end > for almost all of them? You're correct that this will change the commit id of imported svn revisions -- the new verson of git-svn will give other ids than the old version. However, the only thing that's going to "break" is that two separate imports of the same repository with the two different versions of git-svn will not give the exact same result on the git side. I think this is a good change, and it would be a pity if this and other changes like it had to be dropped out of a desire to keep the svn -> git transformation function forever fixed. (IIRC, such changes have been allowed in the past -- e.g. 0bed5eaa: "enable follow-parent functionality by default".) One could imagine a policy of not introducing this kind of change during a stable version, or some such, but historically that's not been the case as far as I can remember. -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle -- 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