Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 25. juli. 2008, at 02.01, Johannes Schindelin wrote:

Um, what?  This discussion is about figuring out when Git should mess
with the line endings a user is trying to commit.

This discusion is about when Git should mess with _content_ at all.

It is not limited to line endings.

Fair enough. Did you read the rest of my email to see when I think Git should mess with content? I've thought about it, and being able to do stuff like this in .gitattributes would work for me:

* eol=auto
*.bat eol=crlf
Makefile eol=lf
bin/magic-binary eol=none

I.e. "detect line endings and do CRLF->LF conversion on all files except *.bat (*->CRLF), Makefile (*->LF) and bin/magic-binary (do nothing)".

The closest you can get today is by setting core.autocrlf to "input" and having this in .gitattributes:

*.bat -crlf
bin/magic-binary -crlf

...but "core.autocrlf" is not versioned and applies to _all_ repositories, and anyone who doesn't have the correct setting can mess the repository up. There's also no way of saying "this file should have LF line endings, even with autocrlf=true".

One problem is that the autocrlf setting mixes "I want LF only in my repositories" and "I like to have CRLFs in my working directory" into one config variable. Instead, I'd like to have a config setting that specifies which line ending form I prefer: "when a text file is marked eol=auto, convert LFs to CRLFs on checkout".

Does this make sense to anyone but me?

Ciao,
Dscho "who personally could not care less about CR if it was not for M$'
stupidity"

Well, we agree on that.
--
Eyvind Bernhardsen

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux