Re: [PATCH 3/3] Teach "git branch" about --new-workdir
- From
Marius Storm-Olsen <marius@trolltech.com>
- Date
- Jul 24, 2007, 13:26 UTC
- Message-ID
- <46A5FDF0.3060801@trolltech.com>
- In-Reply-To
- <Pine.LNX.4.64.0707241337470.14781@racer.site>
> BTW a friend reported a CRLF issue on Windows, _in spite_ of > setting the gitattributes appropriately... Did you ever get > something like that?
Hmm, I haven't really had problems with the gitattributes files in the directory of the file to be ignored, but rather .git/info/attributes.
There I have had problems with directories containing spaces. The
escaping of the spaces doesn't work, so even if you do
foo/bar\ baz/file.txt -crlf
it doesn't work. So, you have to do
foo/*/file.txt -crlf
instead.I mainly have the problem with the following:
1) User on Windows is using MinGW port or Cygwin setup with
DOS EOL.
2) Has core.autocrlf=true
3) Files for XML testcases (for example) is checked into
repo on Linux (File contains CRLF EOL, since its crucial
for testing the XML parser)
4) git diff shows all lineending changed, since the
autocrlf tries to convert the files which are really
checked into the repo with DOS EOL.5) You end up adding a bunch of
foo/bar/baz/* -crlf
into your .git/info/attributes file or the like.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 yesThe problem is that currently 6) is 'yes', and turns the file into a LF file, which it shouldn't.
So, to fix the problem the crlf convertor should really check if the file has crlf EOL in the repo, if so, avoid EOL conversion. (6) should be 'no' :-)
-- .marius