Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
- From
Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
- Date
- Jul 24, 2008, 21:30 UTC
- Message-ID
- <3B9933A6-9637-41AE-9133-9B6EA9204E6B@orakel.ntnu.no>
- In-Reply-To
- <alpine.DEB.1.00.0807232041570.8986@racer>
On 23. juli. 2008, at 21.44, Johannes Schindelin wrote:
[...]
Show 5 quoted lines
> 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.