RFC: safe pattern matching for problematic encoding

Matt Mackall mpm at selenic.com
Fri May 25 13:50:23 CDT 2012


On Fri, 2012-05-25 at 10:53 +0200, Martin Geisler wrote:
> Matt Mackall <mpm at selenic.com> writes:
> 
> > http://mercurial.selenic.com/wiki/EncodingStrategy#The_.22makefile.22_problem
> 
> I honestly don't buy this argument and neither does anybody else that
> I've discussed it with here. Before you start yelling: this is not
> trolling, I'm seriously trying to figure out why this is important to
> you

Trolling is when you knowingly do something that's annoying and is
likely to provoke a frustrated response. You should well know that I am
sick to death of this topic, ergo you are a troll. Being a sincere troll
doesn't make me love you more.

>  and if it even works the way you think it works.
> 
> The basic problem with the argument is that Makefiles that reference
> non-ASCII files aren't portable to start with!

You've mistaken the example for the principle. It's not about makefiles,
per se, it's about the existence of large ecosystems of tools that are
intentionally encoding agnostic. It affects everything from compilers to
web servers to typesetters.

> I've demonstrated this before and I just demonstrated it again with
> Windows 7 in a VM. Please try cloning
> 
>   https://bitbucket.org/mg/makefile-problem

Now try it with GNU Make from msys. I just did. Works a treat on both
changesets. Also works on Linux and Mac. As it obviously will _with any
tool that hasn't drunk the UTF-16 Kool Aid_.

And thus you've proved my point.

a) important toolchains exist that work JUST FINE across platforms with
the existing encoding strategy
b) changing that strategy will cause a REGRESSION and is therefore off
the table
c) having standard tools like GNU make work trumps human legibility:
software that doesn't compile but that you can still read is not
software, it's merely literature

> Matt, do you acknowledge that we break tools in other ecosystems by not
> transcoding filenames?

Yes. And it simply doesn't matter. I'm not going to trade "breaks ANSI
C/Unix world" for "fixes Java world". And not because I designed
Mercurial for the former, nor because it's obviously the closest thing
to a sane, coherent strategy, but because it would break things that are
working today. There is obviously no solution that will make everyone
happy; betraying existing users to please potential users is a strategy
for eventually having no users.

Now you've wasted another hour+ of my time and predictably gotten
nowhere, because there's exactly zero new information in either your
message or my response that hasn't been repeatedly presented over the
past seven years. That's an hour I could have used doing something
useful, or at least spent without elevated blood pressure. In other
words, you have successfully trolled me. Pleased with yourself, troll?

If you want to do something useful, go work on the VFS layer.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list