ANN: subsume extension

[Peter Arrenbrecht]

On Fri, Oct 9, 2009 at 9:11 AM, Peter Arrenbrecht
<peter.arrenbrecht at gmail.com> wrote:
> 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.

Well, it is broken. Not 'hg subsume' per se, but the workflow I've
been using it with. Looks like I need transplant, after all.
-parren