Do you really want to argue with me about X?

As Mercurial project leader, I'm continually called upon to revisit questions about design choices, style choices, project procedure, and so on.

Unsuprisingly, many of these topics have been discussed in great depth in the many years since the project began. But they regularly reappear as new people join the community. Thus, a rather alarming fraction of my time is spent recapping discussions that have already occurred or bluntly directing people to visit the list archives.

Many of these questions are also moot: the relevant decision was made many releases ago and now can't be unmade without breaking backward compatibility, which I am absolutely loathe to do. So not only is it time-consuming for me to reply to, it's also guaranteed to be a purely academic discussion that might be fascinating for you but just tedious for me.

Among the various decisions that aren't moot for the above reasons, I'm still deeply uninterested in revisiting many of them because it's not a good use of time. There's an infinite amount back-and-forth that can be made about any given topic of interest, but time is a scarce resource so at some point it makes sense to make a decision and stick to it and refuse to waste any more time on it.

Every project choice also means I have to say "no" to someone. This part of my job is really unfun, but it's also unavoidable. Please don't make me do it more often or forcefully than necessary.

Some of the most well-worn topics include:

• branches/tags/bookmarks design choices

• diff vs diff --git
• diff/status vs merge semantics
• copy/rename semantics

• unicode on Windows (see WindowsUTF8Plan and EncodingStrategy)

• turning color/pager on by default

• invertable hgignore rules

• changing config file settings from the command line

• using email for code review (remember, I have a huge stake in this topic)

• internal API stability

• Python 3 (see SupportedPythonVersions)

• various CodingStyle choices

• basically anything to do with Git (aka "omg fml")

(And if I've directed you here, your topic too!)

Finally, if you really want to change my mind about something (very rare but not impossible), you'll need to convince me that you've read all the past discussion on the topic and have something actually new and important and non-obvious to say about the topic. If you instead choose to argue by persistence or appeal to numbers/n00bs/git, I'll probably just wish you luck on your fork of the project and get back to work.