Last day to vote/reject on proposed EOL names

[Mark Hammond]

> You're counting on every users editor to do the right thing.  They
> don't.  So the alternatives are this, pre-processing at point of use,
> using hooks to prevent commits reaching the repo with incorrect
> content.

I'd argue for simply preventing the commit from succeeding.  IIUC, this is
only likely in practice if, say, someone on Windows edits this shell script,
then checks it in without testing it.  If they tested it (say, using
cygwin), they would detect the breakage.  The other scenario seems to be a
linux user makes changes to the Visual Studio project file - again, without
testing.  In both these cases the user was (a) using a brain-dead editor and
(b) probably has no real business changing that file in that way.  Therefore
I'd think rejecting the checkin is a safer option - they may have *meant*
the file to be checked in that way for some different scenario - rejecting
the change means they can either (a) fix the file, or (b) fix the rule for
that file.

"In the face of ambiguity, refuse the temptation to guess."

Maybe that's the obvious point I'm missing and it *will* work that way -
that the working tree processing truly is a 'conversion', but the repo
format is simply an 'accept/reject' rule?

Cheers,

Mark