On Mar 3, 2008, at 1:45 PM, [EMAIL PROTECTED] wrote:

On Mar 1, 1:15 pm, Steffen Prohaska <[EMAIL PROTECTED]> wrote:
Hi,
I uploaded the installer Git-preview20080301.exe, which includes a
recent master of official Git, includes git svn, and has
core.autocrlf=true as its default.  It also includes recent bug
fixes from our devel branch.  See the release notes for further
details.

Could I suggest that the release notes also mention the line of code
that is used for setting the CRLF to false and you kindly provided in
the other thread, namely:
git config --global core.autocrlf false

I could add this.  However, I recommend against using it if you are
working in a cross-platform environment (see below).


In order to test this version, I copied twice the directory where I
have my main repository to test both settings of autocrlf. I have two
branches there: the master one and the "development" one (actually, I
have a third one but it is dead and I haven' used it for months).
Before installing the new version of git, the current branch was the
development one.

Working on the first copy: I used the default (or set autocrlf to
"true"). Firstly, git-gui detects all my files as "changed". I have to
select them all and commit this as a big "CR/LF change" commit.
Afterwards I can checkout the master branch (or another commit), but I
cannot come back to the development branch. git-gui complains and
refuse to move back. The error window says "File level merge required"
then "Entry 'foo.bar' not uptodate. Cannot merge." then "Staying on
branch master" where foo.bar is the name of one of the files in the
directory.

You would not see such problems if you had set core.autocrlf true
from the very beginning.  If you had set autocrlf true before your
initial commit, git would have converted all CRLF to LF and
everything would now run smoothly.

Now that CRLF has crept into your repository you have no other
choice, if you want to use autocrlf=true, than forcing a checkout
of all branches and committing a "CR/LF change" commit on all
branches.  Afterwards merging and branch switching should again
work as usual.


If I set the autocrlf to false and work of the second copy of my
repository, everything works fine. No change is seen in the files, and
I can checkout the master branch and come back to development one.
Even better, with the setting on "false", I can also work fine on the
first copy again and check out the development branch there.

Yes you can work with autocrlf=false for Windows-only or for Unix-only
projects.  But if you want to develop on both platforms the only
sane choice is autocrlf=true on Windows and autocrlf=input on Unix.
This choice guarantees that your repository will always stay clean
(LF-only) and you have the native line endings on Windows and Unix.

                Steffen

Reply via email to