On Mar 4, 12:09 am, Steffen Prohaska <[EMAIL PROTECTED]> wrote:
> On Mar 3, 2008, at 1:45 PM, [EMAIL PROTECTED] wrote:
>
[...]
>
>
> > 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.
I started using msysgit in september, and used the default then. I
guess that was false at that time (I do not remember having set it to
false myself)
> > 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
Well, I will stay with autocrlf=false because use of unix is not
planed in my company. If it were to change, I would do what you said
above (applying the CRLF commit to all branches). It solved the error
message when coming branch to development after checking out the
master.
Thanks again for the hint and for the general work with git.
Olivier
