Re: [PATCH 3/3] Teach "git branch" about --new-workdir

[Marius Storm-Olsen <marius@trolltech.com>]

[-- Attachment #1: Type: text/plain, Size: 3287 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]