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