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

On Tue, 13 Feb 2007, Johannes Schindelin wrote:

On Tue, 13 Feb 2007, Alexander Litvinov wrote:

quoted

When I have file that was converted from dos to unix format (or from 
unix to dos) git genereta big diff. But anyway, c++ compiler works well 
with both formats and in this case I simply convert file to dos format 
and git shows again nice diff. If unix format was commited to git I 
simply change the format and commit that file again.

That's awful!

quoted

The only trouble is the rebase, it does not like \r\n ending and othen 
produce unexpected merge conflict. But I don't use rebse to othen to 
realy investigate and try to solve the problem.

Well, if everybody thinks like you, maybe we do not have to change 
anything for Windows after all?

No no no.

It's going to be _horrible_ if people start interesting projects in 
Windows, and there are files in a git repository that are encoded with 
CRLF. 

I'd much rather just get this right, and that means "no hooks". If people 
start using commit hooks etc, that will just mean that they won't use them 
for all-windows environments (why use it? Everybody hass CRLF, and 
everybody _wants_ CRLF), or it will just be relatively expensive to have a 
complex hook anyway.

So I think we should plan on something like .gitattributes or similar, so 
that we _can_ handle mixed environments well, without any real setup or 
any real costs.

The costs really shouldn't be too high - we tend to avoid doing any 
expensive working tree changes *anyway*. For example, even "git checkout" 
has a huge optimization to avoid rewriting files that are already ok, so 
doing things like switching whole branches usually wouldn't even need any 
conversion for most files - even on platforms like Windows that need the 
conversion in the first place.

So considering that it looks _trivial_ for git-update-index, fairly easy 
for diff generation, and I doubt "git checkout" is really likely to be any 
worse either, this should just be somethign we do.

The *ONLY* case where we may not be able to do things automatically is 
actually a much more subtle one: "git cat-file". If we just get a SHA1, we 
don't know what the path to look it up was like, and thus we can never 
know whether it's a binary or a text object. With "-p" we can trivially 
guess, of course, but "git cat-file blob" simply must not do that!

But that really doesn't sound like a big problem to me ;)

		Linus