Johannes Schindelin wrote:
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.
Ciao,
Dscho
In my work flow, I am using a pre-commit script that (among other
things) rewrites all text files to have \n endings. This is a one-way
conversion, and does work well for the set of tools I am using. The
converters I use I wrote years ago, and are smart enough to deal with
mixtures of \n, \r\n, and \r line endings in one file, transforming all
into one unified form. d2u / u2d were not that robust when I last tried
them (years ago), but this is an absolute necessity.
However, I don't think the one-way conversion is acceptable across the
board. While the only Windows editor I am aware of that doesn't grok \n
is Notepad (the moral equivalent of edlin), I suspect that undo reliance
upon this will still lead to grief. If nothing else, someone, somewhere
will find that their beloved crlf's are missing and will complain.
Loudly. And in the lore, git will become known for being "wierd." So, I
suspect a checkout script is necessary.
Mark
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html