On Sun, Feb 14, 2010 at 12:59 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Sat, 13 Feb 2010, Erik Faye-Lund wrote: > >> I don't think it affects svn dcommit in any way, except from the >> implicit svn rebase that svn dcommit performs. d3c9634e sets >> core.autocrlf to "false" on init, but re-enabling it hasn't shown any >> problems in my end. I'm using git-svn with these patches and >> core.autocrlf enabled every day at my day-job. > > To elicit a warm and fuzzy feeling about your patch, you will have to > analyze the code paaths of dcommit, and how crlf affects them. Then you > will have to describe why dcommit does not have a problem with crlf with > your patches anymore. > > Remember, the idea of a commit message is to optimize the overall time > balance, i.e. avoid the many to perform what the one can do for them. And > since you have to do that analysis for yourself anyway, it makes sense to > write up the result in the commit message. > I'm sorry, but I'm confused. What missed from my commit message? The question of dcommit was a question that Eric asked, and I'm not really sure why he did. I tried to explain why in my reply. d3c9634e never was about dcommit the way I understand it, but about clone: http://code.google.com/p/msysgit/issues/detail?id=232 If there's something that isn't sufficiently explained in the commit message, I'd like to know so I can improve it for the next round... -- Erik "kusma" Faye-Lund -- 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