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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 14, 2009, 18:47 UTC
Message-ID: <7vfx9lersc.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.00.0910141601580.4985@pacific.mpi-cbg.de>

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

Show 5 quoted lines

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