[Python-Dev] Hg: inter-branch workflow

Paul Moore p.f.moore at gmail.com
Mon Mar 28 12:13:55 CEST 2011


On 27 March 2011 20:15, Neil Schemenauer <nas at python.ca> wrote:
> Guido van Rossum <guido at python.org> wrote:
>> What is "rebase"? Why does everyone want it and hate it at the same time?
[...]
> The other school, which I am a member of, considers a logical
> development sequence more important than actual development history.
> I like to see a feature or fix developed in smallish, logical steps
> and I'm willing to spend a lot of time to rewrite patches to make it
> happen.  IMO, future maintainers will thank you for the effort.

This philosophy is essentially what the "mq" extension to Mercurial
tries to capture. In mq, you maintain a series of patches "on top of"
your repository, amending, refining and rebasing them as you wish
until they are ready to commit, at which time you take them off the
patch queue and convert them into final commits in the repository.

The one downside of mq is that you do not get the usual benefits of
distributed version control - local commits of your work, branching to
manage experiments, etc. This isn't really surprising, as that sort of
"messy" development doesn't really fit with a nice clean picture of
logical and well-defined patches (at least, it doesn't fit easily
enough that it can be automated :-)). There is a facility in mq to try
to integrate the two, by versioning your patch queue, but that makes
my head hurt, so I can't really comment on how useful that is...

For people in the "clean history" school, I'd recommend looking at mq
for your personal use. But it's definitely an advanced feature of
Mercurial, so it may be better to understand core Mercurial (and at
least temporarily accept that Mercurial is based on the "keep all
history" school of thought, or you'll struggle to match the
assumptions of the documentation to your thinking :-)) before diving
into mq.

Paul.

PS You can do everything that mq provides using core Mercurial
commands - and in theory, do it more safely - but it won't necessarily
fit the way you think quite as well...


More information about the Python-Dev mailing list