Line ending translation extension
Douglas Philips
dgou at mac.com
Mon Sep 7 07:13:03 CDT 2009
Wow, this has been quite a prolific thread, so much so that I'm not
sure if this suggestion has been made and I've missed it, or not:
On or about 2009 Sep 7, at 4:47 AM, Paul Moore indited:
> Consider a repo with all files mandated to use \r\n line endings. Now
> say that you clone that repo, add a new file, then commit and push. I
> would be very surprised if the file you added (on Unix) did *not* have
> \n line endings - for it to be otherwise would require your tool to
> look at other files in the directory and somehow guess that \r\n line
> endings are required for new files. So you've now violated the EOL
> policy for the repo.
In a DVCS, policy decisions (such a line endings) can only be enforced
by hooks running on the repos wishing to enforce those policy
decisions. Anyone who can clone your repo, can make changes: with
funky line ending mixings, funky mixed character encodings, tabs and
spaces, whatever they want. That is the point of a DVCS. It seems that
what you want is to have a set of hooks on your "we care about these"
repos that will reject any changesets that violate your style. As an
example, NetBeans has a number of hooks to enforce their requirements:
http://wiki.netbeans.org/HgHowTos#section-HgHowTos-ServerHooksAbortPretxnchangegroup.somethingHookFailed
(or: http://bit.ly/bA3d0)
You can even suggest that folks who clone your repo(s) set up commit
hooks for their local repos, so as to catch the same issues that your
shared repos will catch. This way when they try commit locally they'll
be warned/prohibited and can fix their stylistic violations sooner
rather than later.
--Doug
More information about the Mercurial
mailing list