On Jan 14, 2008, at 2:50 AM, Junio C Hamano wrote:
Recently I looked at the following patches and topics but I do not think any of them belongs to 1.5.4. None of them is obvious and trivially correct fix to regressions or serious existing bugs:
[...]
* crlf (Steffen Prohaska and Dmitry Potapov)
[...]
I am hoping that authors will resend the ones they really care about after 1.5.4, as I do not want to take patches early.
Thanks for your update on this. I agree with your opinion, although I'd prefer to have the safecrlf option soon. Without safecrlf I'll not enable core.autocrlf=true in msysgit. Now that I see a reasonable way of having at least a warning about potential data corruption when core.autocrlf=true, I'm even stronger against enabling it without a safety valve. As I pointed out in the recent CRLF discussion, I believe the problem is not specific to Windows but is about a reasonable default configuration for cross-platform projects. CRLF conversion must be enabled on all platforms to have good defaults for a mixed Unix/Windows environment, and hence the safecrlf if also needed on all platforms. So I don't see much value in having the safecrlf only in msysgit and not in official git. Junio, Do you see a chance to have safecrlf in 1.5.4.1? I am currently considering wether it is worth following the maint series of official git with msysgit. That is we'd have a maint branch in msysgit, which would merge from Junio's maint. Although we're still in preview mode with msysgit I tend to believe that this would be a good idea. The preview tag is mostly due to the unspecified set of features of msysgit, not that I think part of msysgit is not already very stable and usable. But msysgit only supports a subset of the commands of official git and we don't really say or even know which commands currently work reliably. It could be worth to compile such a list and only install the commands that we are convinced of being ready for production. Steffen - 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
