Robert Luberda <robert@xxxxxxxxxx> wrote: > I have been quite a busy recently, so it took me longer that I thought. No worries, thanks for following up. > It was quite hard for me to think some sensible option name, and finally > have chosen --trim-svn-log (svn.trimsvnlog as config key name). Please > let me know if such name is ok for you. If not, I'll try to find a > different one (but as I wrote I'm not really good at giving names to > options/functions/variables, etc. :() I think having "svn" in "svn.trimsvnlog" twice is redundant and not ideal. Perhaps just --trim-log and svn.trimlog? > I considered making the option a default one for new git svn clones, so > that existing repositories would use the older approach, but I gave up > the idea, and implemented the simpler solution, in which the option must > be given explicitly if one needs the new behavior. If making it a > default for new clones would make sense for you, I can try to implement > this as well. Default behavior should not change, especially not without warning. > For consistency, the `--add-author-from' option was modified not to add > an extra new line before 'From: ' line when the newly introduced option > is in effect. OK. > I'm sending a new patch in next e-mail, could you please look at it and > share any comments you might have? One thing I was not sure about is the > requirement, introduced in the change, of having a whitespace character > after a colon in pseudo-header lines > (e.g. `From:somebody <somebody@xxxxxxxxxxxxx>' won't be considered as a > pseudo-header) - is this consistent with a way git handles > headers/pseudo-headers? Both git-send-email and git-am check for space after these headers, so git-svn should, too -- 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