I'm weary of this topic

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.

Topics that are ''moot''

( because of backward compatibility)

• branches/tags/bookmarks design choices

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

Topics where we've worked out a solution that is in some stage of progress

• unicode on Windows (see WindowsUTF8Plan and EncodingStrategy)

• turning color on by default
  • color should move to core, then this might be an interesting discussion
• turning pager on by default

  • pager still has rough edges around aliases and other corners

  • It seems that as many users are staunchly opposed to pager as are strongly in favor of turning it on

Topics which are technically infeasible, or would introduce more complexity than I'm willing to accept

• invertible hgignore rules

• changing config file settings from the command line
  • Our format wasn't designed to be machine-editable, so performing
    • edits without corrupting existing files isn't necessarily feasible.
  • Programmers are the primary market for Mercurial, and a
    • programmer who is uncomfortable with a text editor is roughly like a surgeon that is uncomfortable with a scalpel.

• internal API stability

Other topics (often [[http://black.bikeshed.org/bikesheds]])

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

  • better tools are welcome, but at present reviewer time is by

    • far the scarce resource for the project, so optimizing for those who are performing reviews is the current optimization priority

• Python 3 (see SupportedPythonVersions)

  • Some volunteers are tinkering with this, but it's not a priority.

• various CodingStyle choices

• Asking about a Git feature (aka "omg fml".)
  • It turns out the author of Mercurial has very limited experience
    • with git, so you're better off describing what you'd like to do in plain English.

(And if I've directed you here, your topic fits into one of those categories!)

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.