[Tim, wondering why the 3.2 branch isn't "inactive"]
... So let's try a different question ;-) Would anyone _object_ to completing the process described in the docs: merge 3.2 into 3.3, then merge 3.3 into default? I'd be happy to do that. I'd throw away all the merge changes except for adding the v3,2.5 tag to .hgtags.
The only active branches remaining would be `default` and 2.7, which is what I expected when I started this ;-)
[Brett Cannon]
While I would think Georg can object if he wants, I see no reason to help visibly shutter the 3.2 branch by doing null merges. It isn't like it makes using hg harder or the history harder to read.
Well, why do we _ever_ do a null merge? Then why don't the reasons apply in this case? What happened here doesn't match the documented workflow - so one or the other should be changed. It has proved tedious to find out why this exception exists, and the only reason I've found so far amounts to "the RM didn't want to bother -- and the only record of that is someone's memory of an IRC chat". As mentioned before, if a security hole is found in 3.2 and gets repaired there, the poor soul who fixes 3.2 will have all the same questions when they try to forward-merge the fix to 3.3 and default. Because the merge wasn't done when 3.2.5 was released, they'll have a pile of files show up in their merge attempt that have nothing to do with their fix. Not only the release artifacts, but also a critical fix Antoine applied to ssl.py a week after the 3.2.5 release. It turns out that one was already applied to later branches, but I know that only because Antoine said so here. Do the "null merge", and none of those questions will arise. And, indeed, that's _why_ we want to do null merges (when applicable) in general - right? So that future merges become much easier. BTW, it's not quite a null-merge. The v3.2.5 release tag doesn't currently exist in the 3.3 or default .hgtags files. So long as 3.2 has a topological head, people on the 3.3 and default branches won't notice (unless they look directly at .hgtags - they can still use "v3.2.5" in hg commands successfully), but that's mighty obscure ;-)