Hi,

On Sun, 14 Feb 2010, Erik Faye-Lund wrote:

quoted text
> On Sun, Feb 14, 2010 at 12:59 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > 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?

I had the impression that you sent a mail asking to revert the commit that 
hardcoded autocrlf to false for git svn. For that commit, you would have 
to provide the information I requested.

quoted text
> 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

Well, technically, you are right, it is only about clone.

But.

If you set autocrlf to false in every git svn clone, then of course, 
dcommit is very much affected by the setting. Along with all other git svn 
operations.

And since your patches aimed at undoing that patch, i.e. no longer setting 
autocrlf to false upon git svn clone, you have to show that git svn in 
general can handle autocrlf = true (or = input) just fine.

And by "to show" I do not mean just test it. That is not good enough, 
because your workflow is more than just likely to miss out on ways other 
people use git svn. You have the source code, and you can look all git 
calls and analyze them for potential autocrlf problems.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html