From: Torne Wuff <torne+rockboxdev_at_wolfpuppy.org.uk>
Date: Wed, 6 Jul 2011 16:57:09 +0100

OK: we did discuss this at devcon somewhat, but I just want to make
sure we are all on the same page before I do any giant commits ;)

We're not very good at keeping consistent line endings in the
repository: there are a few files in there right now which have CRLFs
in them for no good reason, and there are many files that don't have a
svn:eol-style set on them even though they currently have the right
line endings. People using windows/cygwin experience various issues
with line endings breaking builds depending what svn client they use
to check out the code.

Git makes this much easier to handle consistently and I intend to
ensure that *all* text files checked into the git repository (once we
migrate) are normalised to LFs, but there's still one question: do we
want to force files to have LF on checkout, or do we want to allow
them to be converted to the platform's native line endings (for the
hypothetical people who use windows/cygwin but want to have CRLFs
because of some tool they use that doesn't understand LFs)?

Either way, git can enforce normalisation on checkin trivially, and it
doesn't depend on per-file properties which someone has to remember to
set, so it will be applied consistently to *all* non-binary files
without any possibility of ending up with a mixture.

I guess this ultimately comes down to: do we want to force anyone who
checks out the tree on Windows to work with UNIX line endings so that
we don't have to care if our build process handles CRLFs, or do we
want to let people configure their Windows git client to taste (it
will, by default, convert to CRLF, but individual git users can turn
that off) and maybe get potential build issues from it?

-- 
Torne Wuff
torne_at_wolfpuppy.org.uk

Received on 2011-07-06