[msysgit? bug] crlf double-conversion on win32

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).

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

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"

Hi,

On Tue, 13 Oct 2009, Eric Raible wrote:

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

On Wed, Oct 14, 2009 at 16:03, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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.

On Wed, Oct 14, 2009 at 7:03 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

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.

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

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.

On Wed, Oct 14, 2009 at 11:47 AM, Junio C Hamano <gitster@pobox.com> wrote:

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