Re: mingw, windows, crlf/lf, and git
- From
- David Lang <david.lang@digitalinsight.com>
- Date
- Feb 12, 2007, 23:46 UTC
- Message-ID
- <Pine.LNX.4.63.0702121544550.6630@qynat.qvtvafvgr.pbz>
- In-Reply-To
- <7vfy9b6iyt.fsf@assigned-by-dhcp.cox.net>
On Mon, 12 Feb 2007, Junio C Hamano wrote:
Show 24 quoted lines
>> 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.
the expectation is that the some-of-each situation is unlikly to happen if you convert all the time.
and if you do end up with a mixed ending file, the next time you check it in from a windows box it should clean it up.
David Lang