Hi,

On Mon, 12 Feb 2007, Junio C Hamano wrote:

quoted text
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > Hi,
> >
> > On Mon, 12 Feb 2007, Junio C Hamano wrote:
> >
> >> I agree that we can assume editors can grok files with LF end-of-line 
> >> just fine and we would not need to do the reverse conversion on checkout 
> >> paths (e.g. "read-tree -u", "checkout-index").
> >
> > In that case, a simple pre-commit hook would suffice.
> >
> > No, the problem mentioned by Mark was a very real one: you _cannot_ rely 
> > on Windows' editors not to fsck up with line endings. The worst case is if 
> > the file contains _some_ CRLF and _some _LF_. Almost always I had the 
> > problem that it now converted _all_ LFs to CRLFs. Even those which already 
> > were converted.
> >
> > So, if we are to support text mode, it is not one-way. If we do one-way, 
> > we really do _not_ support text mode, but pre-commit conversion to LF 
> > style text. And in this case, core git does not need _any_ change.
> 
> Well I disagree in two counts.
> 
>  - I do not see how you propose to solve some CRLF and some LF
>    case with both-ways conversion.

Very easy. Forward: s/\r\n/\n/. Backward: s/\(^\|[^\r]\)\n/\r\n/.

quoted text
>  - Pre-commit hook would not be sufficient.  In a edit, diff,
>    test and then commit cycle, diff and test step needs to look
>    at whatever the editor left on the filesystem, so the changes
>    to populate-filespec is needed to make diff part work.

Yes, you are right.

However, since this is all post-1.5.0 (right? Right?) why not go with more 
of Ted's proposal, and make this whole mess also usable for other things 
than just crlf issues?

And I _really_ think that you do not help Windows people by doing this 
one-way thing.

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