[Brett] > ... > After reading that sentence I realize there is a key "not" missing: "I see > no reason NOT to help visibly shutter the 3.2. branch ...". IOW I say do the > null merge. Sorry about that.
No problem! Since I've been inactive for a long time, it's good for me to practice vigorously defending what's currently documented - tests my understanding, and lets me annoy people at the same time ;-) Here's what I intend to do (unless an objection appears): hg up 3.3 hg merge 3.2 # merge in the v3.2.5 tag definition from .hgtags, # but revert everything else hg revert -a -X .hgtags -r . hg resolve -a -m hg diff # to ensure that only the v3.2.5 tag in .hgtags changed hg commit and then much the same steps to merge 3.3 into default. BTW, "null merging" this way is annoying, because at least in my installation kdiff3 pops up for every uselessly conflicting file. Anyone know a reason not to do: hg -y merge --tool=internal:fail 3.2 instead? I saw that idea on some Hg wiki. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
