Re: mingw, windows, crlf/lf, and git

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 14, 2007, 16:53 UTC
Message-ID: <Pine.LNX.4.64.0702140847020.3604@woody.linux-foundation.org>
In-Reply-To: <45D335C3.E28D28E0@eudaptics.com>

On Wed, 14 Feb 2007, Johannes Sixt wrote:

>
> Thanks a lot, busy beaver! I gave this a quick spin with a few
> interesting operations: merges and rebase. Merges leave the merge
> results with only LFs behind.

Yes. Merge uses "git-cat-file" (well, it historically did, now that it's built-in it still does the equivalent operation).

I already talked about how git-cat-file was special ;)

> Rebasing seems to work as expected (working files have CRLFs), except 
> when merges are needed.

Well, it always "merges", but yes, you mean three-way data merges. The normal SHA1-direct merges will just use the normal git-read-tree thing which is the same as checkout.

> Doesn't git-unpack-file also need to call into the converter?

See earlier discussions. git-cat-file (and git-unpack-file, which is just a version of it, really) don't have the original filename, so we'll need to extend on it some way in order to support file attributes even in theory. So before we do that, I'd hate to do any format conversion there.

Yes, yes, right now it ignores the filename *anyway*, but the point is, right now that's a "small implementation detail". I would NOT want to do this if I couldn't know the filename at all!

The merge algorithms actually obviously *do* know the filename fo the things that they are going to merge, so the filename information does exists. It's just not passed on far enough.

Finally, one comment: if you use "autocrlf = input" (my second patch), all of this works even now, since the default is to just leave things as LF-only anyway. In fact, even with "autocrlf = on", nothing should really *break* except for silly editors that actuall *require* CRLF.

IOW, it's more important to do the CRLF->LF conversion than it is to do the LF->CRLF one ;)

		Linus