Re: [PATCH 3/3] Teach "git branch" about --new-workdir
- From
Marius Storm-Olsen <marius@trolltech.com>
- Date
- Jul 24, 2007, 18:02 UTC
- Message-ID
- <46A63EAA.6080203@trolltech.com>
- In-Reply-To
- <Pine.LNX.4.64.0707241431540.14781@racer.site>
Show 17 quoted lines
>> So, it's look like this ('yes' mean CRLF EOL):
>> Repo | Working dir | Convert EOL?
>> ---------------------------------
>> 1) - LF no
>> 2) - CRLF yes
>> 3) LF LF no
>> 4) LF CRLF yes
>> 5) CRLF LF no
>> 6) CRLF CRLF yes
>>
>> The problem is that currently 6) is 'yes', and turns the file into
>> a LF file, which it shouldn't.
>
> Shouldn't it? But then you should set core.autocrlf = false, no?
>
> AFAIU the purpose of autocrlf is to _always_ have UNIX line endings
> in the checked in stuff.I realize that I might be talking 'out of context', so to speak; so it's hard to see where I'm going with this. So, I'll start from the beginning. :-)
1) IMO, git should on Windows always do CRLF conversion, as this is what
Windows developers in general expect. (CRLF text-files that is, not the
conversion.) Meaning that
core.autocrlf = Windows
by default. Where 'Windows' would be of true/false value which is true
when on Windows and false when on other platforms. (Not that we should
_have_ such an option, but the concept at least.)2) Most Windows developers in the category above currently do
git-config --global core.autocrlf true
once, and be done with it.
However, for every text-file they want in the repo which _should_
contain CRLF EOLs they would have to add this file to either a
.gitattributes file in that same directory, or to
.git/info/attributes
with the
<filepath> -crlf
to ensure that the autocrlf conversion is not triggered for those files.
Now, for Unix users that seems like a small price to pay, and of course
_they_ don't have to worry about it. It's up to the Windows developers
to take the pain and add these .gitattributes files, and keep track
whenever new CRLF files appear in the repo from other non-Windows
developers.3) My suggestion in the previous mail would to a large extent alleviate this problem, since once in the repo with CRLF lineendings the 'autocrlf conversion' routine wouldn't automatically try to convert it back to LF endings, even if this file is not in any attributes file with '-crlf'.
It would mean that we wouldn't have to add _any_ files to attributes
files at all, but only have to teach git a way to avoid crlf-converting
a given file when commiting a change. For example, on Windows you could
then do something like:
git update-index --crlf my_DOS_file.txt
git commit -m "Add a CRLF file to the repo"
then forget about it.No need to add a .gitattributes in your own repo. No need for linux users to worry about Windows users. No need to Windows users to clean up the repos for the linux users.
IMO, the .gitattributes file with '<filepath> -crlf' is a hack-fix to a problem we shouldn't be having in the first place. We should be able to write in the git documentation: "Text files are stored with Unix line ending in Git. If you need a text file to contain DOS line endings on all platforms, use the --crlf option on the update-index command."... or something to that effect.
Ok, a bit longer mail than I expected/wanted, but I hope it explains the idea successfully, and convincingly. ;-)
Later!
-- .marius