Uncommitted changes and merge

[Giorgos Keramidas]

On 2007-09-06 19:24, Guido Ostkamp <hg at ostkamp.fastmail.fm> wrote:
>> Without MQ, you would have to *commit* the local changes and then
>> merge with the parent.  Future changes to the local patches would
>> have to appear in the history as standalone changesets, and some
>> people (me included) hate having to skim through tons of history to
>> see the changes of a single bugfix or feature.
>>
>> With MQ, you can keep as many local patches as you want, keep
>> refining and refactoring the local patches, up to the point where
>> they are ready for 'commit'.  Then you commit them locally and merge
>> as usual :-)
>
> As someone who seems to be regularly using MQ stuff, can you let us
> know your opinion regarding using a 'queue repository' (with 'hg
> qcommit' etc.) vs. the 'hg qsave' and 'hg restore' commands?
>
> What is best?

There is probably no "best" way of working with MQ.  I am commonly using
"qinit -c" and "qcommit" to save the patch state of the bug fixes I am
working on, but I can imagine using "qsave -c" to save multiple copies
of the same patch queue even when _both "qcommit" and "qsave" are used.

Most of the time, I am using MQ with short patch queues, to develop
local changes for bug fixes at work.  The "official" repository is
stored across the world, in a Perforce depot, but I find the delays
incurred by this WAN-based repository totally unacceptable for my style
of work.

Enter MQ to the rescue.

I keep a local "hg repo" synchronized periodically with Perforce, as a
"master tree".  Then I clone the "master" repo every time I want to do
serious work and prepare my patches using MQ of local commits.  Most of
the time I use MQ so I can work concurrently on multiple bugfixes in the
same "personal" clone.  This way I can use MQ to shape and refine my
patches until they reach a form that satisfies me, and I can extract a
single diff/patch for every fix.

When I wrote above that I use both "qcommit" and "qsave" I meant that
qcommit is useful when:

  - I have a patch with tons of changes, but I want to experiment with
    an alternative approach, I use "qcommit".  This way I can keep
    working in the same patch queue, without interrupting the "flow" of
    thoughts I have at the moment. If the alternative method turns out
    to be a fancy way of breaking the fix, I can roll back the patch
    queue and return to a "known patch state".

  - I want to prepare a patch for review by fellow developers, but keep
    working on more details of the same patch.  Then I "qcommit", push
    just one patch on top of the "base" tree, run Sun's cool "webrev"[1]
    utility to prepare a nicely formatted set of static HTML pages, post
    the "webrev" output online, and keep working on my patch.

    [1] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/tools/scripts/webrev.sh

  - I want to work on multiple bug fixes in the same clone.  Then I
    commonly use "qcommit" to save the active state of the patch queue
    before "switching tasks", to make sure I don't lose work-in-progress
    changes because I forgot something during the mental context switch.

I'm more experienced with "qcommit" for saving patch queue state, and it
is easier to publish patch queues online when all patches are
"qcommitted"; i.e. the patch queues I keep at hg.hellug.gr for GNU Emacs
and the doc/ tree of FreeBSD are based on MQ and "qcommit".

On the other hand, I usually find "qsave -e -c" easier when:

  - I have to "rebase" patches on top of some "master" changes tricking
    in through Perforce -> Hg -> "master" repo.  Using "qcommit" may be
    possible, but I've now become a bit acquainted with the "qsave ;
    pull ; update ; qpush -a -m ; qpop -a ; qpop -a -n patches.1" steps
    from the wiki, and I'm a bit afraid of using just "qcommit".

So both "qcommit" and "qsave" are useful to me; just for very slightly
different things.  Their main difference, according to my experience is
that "qcommit" lets me stay "in the flow" of what I'm currently doing,
but "qsave" is a better way to backup an entire patch queue when
rebasing patches.  But that's just _my_ personal view of things, and it
is definitely not something even remotely resembling a "Gospel" :)

I'm not sure if this is what you wanted to know, but there it is...

HTH,
Giorgos