Hi,

On Mon, 10 Mar 2008, Sebastian Schuberth wrote:

> I'm having several autocrlf related issues with the new Git- 
> preview20080301.exe installer.
> 
> The first is rather an oddity than a real problem:
> 
> $ grep autocrlf ~/.gitconfig
>         autocrlf = true
> 
> $ grep autocrlf .git/config
> 
> $ git config --get core.autocrlf
> true
> 
> $ git config --list | grep autocrlf
> core.autocrlf=true
> core.autocrlf=true
> 
> As you can see, "config --list" lists autocrlf twice. Probably the new
> internal default of autocrlf=true is listed here too?

It comes from /etc/gitconfig, yes.

> The second problem in fact seems to have already existed in earlier
> releases, but now became more apparent due to the warning Git is
> issuing:
> 
> $ git config --get core.autocrlf
> true
> 
> $ git branch
>   vi-stable
> * vi-work
> 
> $ git merge origin/qt4
> warning: LF will be replaced by CRLF in amiramain/bin/start
> Auto-merged Amira/HxObject.cpp
> Auto-merged hxcolormapeditor/HxAdvancedColormapEditor.cpp
> CONFLICT (content): Merge conflict in hxcolormapeditor/
> HxAdvancedColormapEditor.cpp
> Automatic merge failed; fix conflicts and then commit the result.
> 
> # Both the "start" and "HxAdvancedColormapEditor.cpp" have Unix line-
> ending at this point,
> # despite autocrlf=true
> 
> $ git mergetool
> Merging the files: hxcolormapeditor/HxAdvancedColormapEditor.cpp
> 
> Normal merge conflict for 'hxcolormapeditor/
> HxAdvancedColormapEditor.cpp':
>   {local}: modified
>   {remote}: modified
> Hit return to start merge resolution tool (ecmerge):
> warning: LF will be replaced by CRLF in hxcolormapeditor/
> HxAdvancedColormapEditor.cpp
> 
> # Again, the warning is correct, but HxAdvancedColormapEditor.cpp
> should have had CRLF instead
> # of LF in the first place
> 
> Moreover, if there is a modified file
> 
> $ git diff --name-status
> M       hxvoltex/SxVoltex.h
> 
> then "git diff" will checkout the temporary file which reflects
> "SxVoltex.h" in the repository also with LF instead of CRLF, i.e. the
> autocrlf setting does not seem to be respected. But this problem also
> was present in earlier releases already.
> 
> Steffen Prohaska already took a quick look at this (but has no time to
> fix it) and thinks handle_file() in builtin-rerere.c is missing the
> conversion and thus causing the problems.

I hope to get some time and motivation tonight to have a look at it, could 
you bug me again tomorrow if I did not?

Ciao,
Dscho

Reply via email to