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

From: Theodore Tso <tytso@mit.edu>
Date: Feb 12, 2007, 04:24 UTC
Message-ID: <20070212042425.GB18010@thunk.org>
In-Reply-To: <45CFA30C.6030202@verizon.net>

On Sun, Feb 11, 2007 at 06:13:16PM -0500, Mark Levedahl wrote:

Show 16 quoted lines

> I am NOT intending to start a flamewar O:-) , so please don't turn this 
> into one.
> 
> The recent threads on a mingw git port are explicit in the intent to 
> provide a Windows native git. I believe there is a fundamental conflict 
> here with the position, clearly stated by Linus, that git does not alter 
> content in any way. Windows suffers the curse of DOS line endings (\r\n 
> vs \n), and a true port to Windows *must* allow for \r\n and \n to be 
> semantically the same thing as most large projects end up with a mixture 
> of such files and/or are targeting cross-platform capabilities. The 
> major competing solutions git seeks to supplant (cvs, cvsnt, svn, hg) 
> have capability to recognize "text" files and transparently replace \r\n 
> with \n on input, the reverse on output, and ignore all such differences 
> on diff operations. To be relevant on native Windows, git must do the 
> same. Otherwise, git will be deemed "too wierd" and dismissed in favor 
> of a tool "that works."

So this is something that I've tried proposing to the Mercurial developers, but it's never been implemented in hg. It'll be interesting to see what the git community thinks. :-)

My proposal does require adding a file type to each file, as tracked metadata, which may doom it from the start. If you add a file type, then you have to support mutating the file type, and some way of handling merge conflicts (generally, picking one type or another).

Then for each file type, we implement a set of interfaces (perhaps as simple as a series of executables named git-<type>-<operation>) which if present, transforms the file from its live format to the canonical format which is actually checked in and back again. Besides using this for the DOS CR/LF problem, it also allows for an efficient storage of things like OpenOffice files which are a zipped set of .xml files. By decompressing them before pushing them into the SCM, it means that if the user makes a tiny spelling correction in their OpenOffice file, the delta stored in the git repository can be much more efficiently stored (since the diff of the .xml tree will be small, where as the diff of the entire compressed file is likely going to be close to the entire size of the .odt file).

Another nice thing to provide for each file type would be a pretty-printer for the diffs, so it becomes easier to see the delta between two versions of an OpenOffice file in a textual window.

So, is this idea sane or completely insane? Hopefully it passes Linus's it-solves-multiple-problems-at-once test, at least. :-)

							- Ted