Re: mingw, windows, crlf/lf, and git
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Feb 12, 2007, 23:50 UTC
- Message-ID
- <Pine.LNX.4.63.0702130046450.22628@wbgn013.biozentrum.uni-wuerzburg.de>
- In-Reply-To
- <7vfy9b6iyt.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 12 Feb 2007, Junio C Hamano wrote:
Show 26 quoted lines
> 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/.
> - 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