On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
[...]
I deem it not, uhm, magical. By your reasoning there should be a
way for
Git to convert a file to UTF-8 when some entertaining person
converted the
working directory file to ISO-8859-15.
Um, what? This discussion is about figuring out when Git should mess
with the line endings a user is trying to commit. Why are you
bringing character encodings into it? Git does not (to my knowledge)
have any "utf8" setting that converts all files to UTF-8, and
certainly not one that is enabled by default on Windows.
Being able to mark a file with an "enforce crlf line endings on this
file" flag is useful _given that Git messes with line endings_, and a
"do not mess with line endings in this file" flag does not achieve the
same purpose. Okay?
If you want my personal opinion on autocrlf, I was happier when Git
left line endings alone so I didn't have to worry about the files I
commit being mangled (however reversibly).
I think "autocrlf=input" can make sense on a per-repository basis, but
I would have it somewhere versioned like .gitattributes, so that (a)
it is propagated when the repository is cloned, and (b) it is possible
to take an existing repository with checked-in CRLFs and do a one-time
conversion that also adds the "autocrlf=input" setting
to .gitattributes (or wherever the setting ends up going).
I don't use "autocrlf=true", even on Windows, so I don't have any
opinion on it other than thinking it should be a per-user setting
rather than per-repository (but with a per-platform default :). I
don't see how it could work unless the repository has normalised line
endings, though.
My background: I have a ton of repositories imported from CVS with a
sordid mix of CR and CRLF (occasionally in the same file!). Using
these repositories with "autocrlf=true" is a pain in the arse since
CRLFs in the repository cause spurious changes after a clean checkout,
merge troubles, etc. The code is supposed to build on Windows as well
as Unix, so I got bit by this when msysgit changed the default
autocrlf setting. [1]
My workaround is simply to set autocrlf=false; another solution might
be to filter-branch all CRLFs out of the repository, but then I'd be
messing with a lot of history, possibly breaking the files that
actually need CRLFs, and for no real upside. No thanks.
Okay, this turned into a longer rant than I intended; what I'm trying
to say is that I think autocrlf(=true) as it is currently implemented
is pretty useless, and that a setting that is versioned and cloneable
would be better. Phew!
--
Eyvind Bernhardsen
Footnote:
1. Your impression that people were rude when "autocrlf=true" was made
the default on msysgit might be related to the fact that nobody had
considered what would happen to existing repositories before making
the change? Steffen Prohaska wrote in response to one such complaint:
Unfortunately, existing repositories that contain the wrong line
endings
suffer from the problems you described above. This can be handled
either by switching off autocrlf, as you propose, or by cleaning up
the
line endings.
(http://groups.google.com/group/msysgit/browse_thread/thread/978a3435c1cb0c81/70bac514a8b438ef?lnk=gst#70bac514a8b438ef
)
Steffen went on to propose a patch to make autocrlf a sticky per-
repository setting, but I think you shot it down.
--
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
