safecrlf not in 1.5.4 (was Re: [PATCH] Teach remote machinery about remotes.default config variable)

From: Steffen Prohaska <prohaska@zib.de>
Date: Jan 14, 2008, 06:49 UTC
Message-ID: <31687420-EB17-4651-AD6C-07213311ABDA@zib.de>
In-Reply-To: <7vir1xmazm.fsf@gitster.siamese.dyndns.org>

On Jan 14, 2008, at 2:50 AM, Junio C Hamano wrote:

Show 5 quoted lines

> 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