Robert Luberda rob...@debian.org wrote:
Junio C Hamano wrote:
Eric Wong normalper...@yhbt.net writes:
I think having svn in svn.trimsvnlog twice is redundant and not ideal.
Perhaps just --trim-log and svn.trimlog?
Do we ever want to trim our log when relaying the Git commits back
Junio C Hamano wrote:
Eric Wong normalper...@yhbt.net writes:
I think having svn in svn.trimsvnlog twice is redundant and not ideal.
Perhaps just --trim-log and svn.trimlog?
Do we ever want to trim our log when relaying the Git commits back
to subversion? Having svn in trimsvnlog makes it
Eric Wong normalper...@yhbt.net writes:
Robert Luberda rob...@debian.org 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
While importing changes from SVN by `git svn fetch' strip any
white spaces from beginnings and endings of SVN commit messages
and skip adding a new line character before `git-svn-id:'
line in case the commit message ends with another pseudo-header
(like From:, Signed-off-by: or Change-Id:, etc.).
Eric Wong wrote:
Hi,
I've long wanted to change this, but it breaks compatibility if folks
are importing from the same repo, sharing changes and one upgrades
git-svn.
Yes, I'm aware of this. That's why in our team at work everybody is
forced to use the modified version of git-svn:)
[ A bit
Robert Luberda rob...@debian.org wrote:
Eric Wong wrote:
How about making this optional and configurable at init/clone time?
I don't think it will be hard to make it configurable. I can try to make
such a change, do you have any preferences about the option and
configuration key names?
No
6 matches
Mail list logo
