From: Steffen Prohaska <prohaska@zib.de>
Date: Mon, 14 Jan 2008 06:49:14 GMT
Subject: safecrlf not in 1.5.4 (was Re: [PATCH] Teach remote machinery about remotes.default config variable)
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:

> 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