[msysgit? bug] crlf double-conversion on win32

[msysgit? bug] crlf double-conversion on win32

[Yann Dirson]

With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
to a Linux box and committed it.

In that situation, the win32 client in autocrlf mode keeps telling that
the files are locally modified, even after eg "git reset --hard".  Without
touching the crlf setting (which I believe should not ever be necessary),
this can be corrected by committing the faulty files after dos2unix'ing
them, and using "git fetch && git reset --hard origin/master" ("git pull
--rebase" refuses to do the job since it believes there are local
changes).

Re: [msysgit? bug] crlf double-conversion on win32

[Eric Raible]

Yann Dirson <y.dirson <at> e-sidor.com> writes:

> 
> With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
> to a Linux box and committed it.
> 
> In that situation, the win32 client in autocrlf mode keeps telling that
> the files are locally modified, even after eg "git reset --hard".  Without
> touching the crlf setting (which I believe should not ever be necessary),
> this can be corrected by committing the faulty files after dos2unix'ing
> them, and using "git fetch && git reset --hard origin/master" ("git pull
> --rebase" refuses to do the job since it believes there are local
> changes).

See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862

In which Junio suggests:
$ rm .git/index
$ git reset --hard

in order to "restore sanity to your work tree"

Re: [msysgit? bug] crlf double-conversion on win32

[Johannes Schindelin]

Hi,

On Tue, 13 Oct 2009, Eric Raible wrote:

> Yann Dirson <y.dirson <at> e-sidor.com> writes:
> 
> > 
> > With a msysgit 1.6.4 package, I got stuck after someone copied a CRLF file
> > to a Linux box and committed it.
> > 
> > In that situation, the win32 client in autocrlf mode keeps telling that
> > the files are locally modified, even after eg "git reset --hard".  Without
> > touching the crlf setting (which I believe should not ever be necessary),
> > this can be corrected by committing the faulty files after dos2unix'ing
> > them, and using "git fetch && git reset --hard origin/master" ("git pull
> > --rebase" refuses to do the job since it believes there are local
> > changes).
> 
> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
> 
> In which Junio suggests:
> $ rm .git/index
> $ git reset --hard
> 
> in order to "restore sanity to your work tree"

Of course this is insane as a user interface.  It is not even plumbing.

So I started some time ago to code a "git checkout --fix-crlf", but I 
am not really happy with the user interface.  I think that Git should 
realize itself that something went wrong with the line endings.  If I say 
"git reset --hard", it is just a bug in Git when it insists afterwards 
that the files are modified.

Ciao,
Dscho

Re: [msysgit? bug] crlf double-conversion on win32

[Laurent Boulard]

On Wed, Oct 14, 2009 at 16:03, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>>
>> In which Junio suggests:
>> $ rm .git/index
>> $ git reset --hard
>>
>> in order to "restore sanity to your work tree"
>
> Of course this is insane as a user interface.  It is not even plumbing.
>
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface.  I think that Git should
> realize itself that something went wrong with the line endings.  If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.

I have to work on win32 at work and depending of projects, I have to
play with autocrlf/crlf config.
So I cannot do a git clone because it will inherit the global crlf
configuration which is not want I want. My flow is often:

$ git init ...
$ git config core.autocrlf ...
$ git remote add origin ...
$ git fetch origin ...

I stuffed those four lines behind a few git alias but I think having a
config option for git init and git clone to set core.autocrlf in
repository would be a (small) improvement, isn't it ?

Laurent.

Re: [msysgit? bug] crlf double-conversion on win32

[Eric Raible]

On Wed, Oct 14, 2009 at 7:03 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 13 Oct 2009, Eric Raible wrote:
>
>>
>> See http://thread.gmane.org/gmane.comp.version-control.git/122823/focus=122862
>>
>> In which Junio suggests:
>> $ rm .git/index
>> $ git reset --hard
>>
>> in order to "restore sanity to your work tree"
>
> Of course this is insane as a user interface.  It is not even plumbing.
>
> So I started some time ago to code a "git checkout --fix-crlf", but I
> am not really happy with the user interface.  I think that Git should
> realize itself that something went wrong with the line endings.  If I say
> "git reset --hard", it is just a bug in Git when it insists afterwards
> that the files are modified.

I fully agree that "git reset --hard" should actually, uh, do a hard reset,
as should be clear in the my reply to Junio's suggestion.  So I'm not
advocating "rm .git/index" as a good solution, but simply one that works.

Re: [msysgit? bug] crlf double-conversion on win32

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> So I started some time ago to code a "git checkout --fix-crlf", but I 
> am not really happy with the user interface.  I think that Git should 
> realize itself that something went wrong with the line endings.  If I say 
> "git reset --hard", it is just a bug in Git when it insists afterwards 
> that the files are modified.

I tend to agree.  "git reset --hard-without-cached-stat-info" that ignores
the cached stat information while it does the equivalent of the usual
"reset --hard" may be a reasonably safe and usable alternative for
"checkout --fix-crlf".  When people see "reset --hard...", it will tell
them that this is about matching the index and the work tree with the
named commit, as opposed to "checkout", so enhancing "reset" would make
more sense, I think.

Obviously, I am not seriously suggesting "--hard-without-cached-stat-info"
as the name of this mode of operation, and you need to come up with a
better one.  But it is better than "--crlf", as it is not limited to the
crlf conversion that brings the inconsistency you will be resetting away.
It arises from any silent invalidation of the cached stat optimization
after you touch attributes and config.

Re: [msysgit? bug] crlf double-conversion on win32

[Eric Raible]

On Wed, Oct 14, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Obviously, I am not seriously suggesting "--hard-without-cached-stat-info"
> as the name of this mode of operation, and you need to come up with a
> better one.

Since we already have --soft and --hard, how about --throbbing?