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

[Theodore Tso <tytso@mit.edu>]

On Sun, Feb 11, 2007 at 06:13:16PM -0500, Mark Levedahl wrote:
> 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