ANN: subsume extension

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Fri Oct 9 07:11:43 UTC 2009


On Thu, Oct 8, 2009 at 10:58 PM, Stephen Rasku <mercurial at srasku.net> wrote:
> On Thu, Oct 8, 2009 at 12:44, Matt Mackall <mpm at selenic.com> wrote:
>> On Thu, 2009-10-08 at 13:38 +0200, Dirkjan Ochtman wrote:
>>> On Thu, Oct 8, 2009 at 13:27, Peter Arrenbrecht
>>> <peter.arrenbrecht at gmail.com> wrote:
>>> > I suppose this could be mentioned in the guide for getting rid of
>>> > unwanted heads. We might also consider having this in Hg's core, as an
>>> > option to merge.
>>>
>>> I'd like that. Maybe hg merge --discard? The word 'subsume' makes me
>>> think a little too hard.
>>
>> I don't think this is the right direction. Dummy merge is a hack that
>> messes up history. We should instead improve head closing and
>> surrounding logic to the point where people don't care any more.

For dangling heads caused by false starts and such, I agree. But see
below for a situation where it actually correctly reflects history.

> Long term I agree with you.  However, this provides a solution for
> already existing repositories.  We have converted our CVS repository
> to Mercurial and it has tons of dangling heads even though the code
> has been merged.  If I could do a dummy merge then I could see which
> branches are merged where without having to decipher it from the
> commit messages.  It will append an extra changeset to the merged
> branch but there's no way to merge to the proper revision without
> changing all the changeset IDs.  It's not ideal but it's better than
> what our repository looks like now.

This is actually akin to the situation that prompted me to start doing
this (originally with debugsetparents). I am tracking multiple
upstream branches where people port changes manually, - so there is no
merge tracking. Nevertheless, I have to assume that they _did_ merge
their work and I need to tell Hg about it so I can later merge my own
changes on top of these branches cleanly using Hg.

In this situation, I think dummy-merges are the correct thing to do.
But I'd like to hear if anybody sees a problem with using subsume
instead of the full-blown merge+revert.

I've run a quick test to highlight the differences
(http://bitbucket.org/parren/hg-subsume/src/tip/test.sh). It has a
base commit "a" and two heads "b" and "c" on top of it. It then
dummy-merges b into c using both merge+revert and subsume. As I
suspected, there are differences. The status after the revert is:

M a-b-modified
M a-bc-modified
M bc-new
R b-new

And indeed these files have additional revlog entries after the merge.
This is because revert only reverts a file's contents, but not its
parent information.

For a-bc-modified and bc-new (which are touched in both heads), this
is arguably more correct than what subsume does. It records the merge
decision in the file's change history. For a-b-modified, however, the
file's own history is actually misleading (while technically correct).
Unless we consult the changelog, we do not see there was a merge, only
that the file was a, then changed to b, then changed back to a.
Contrast this with file a-c-modified, where the merge simply records
the link to the original version from head c. Subsume does the same
for a-b-modified (points straight at its revision from "a").

With subsume, the merge manifest simply records all the files exactly
as they were in c, so it does not introduce new filelog revisions,
only changelog and manifest. You are guaranteed that the dummy merge
is exactly what your desired head was, with no reliance on the
correctness of "revert --all". Also, it does not add new filerevs with
identical content (which could take some memory when binary files
and/or intervening other revs are in the picture).

Now, AFAIK, the file history graph is only used for `hg log -f` and
the like, but not for determining merge ancestors (merge uses the
changelog excusively). So I think subsuming is safe, clean, incurs
less hassle and bewildering messages, and is more space-efficient than
merge+revert.

If there is something broken with this approach, please let me know.

-parren




More information about the Mercurial mailing list