On Tue, 13 Feb 2007, Johannes Schindelin wrote: > > On Tue, 13 Feb 2007, Alexander Litvinov wrote: > > > 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! > > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html