(original) (raw)

\[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 ;-)