Transplanting merge results cleanly?

Matthew Moore mmoaot at gmail.com
Tue Jul 29 12:49:13 CDT 2008


Thanks.  I effectively want to hide the branch so the history of the central
repo shows changes in semantically meaningful units rather than, for
example, commits that happened because I was going home for the evening.
export-ing the merge changeset and then importing it to central is
semantically what I want.  I'm still not clear why transplant needs to pull
in the branch changesets when asked to transplant a merge changeset, but I'm
willing to accept that Mercurial needs to work that way.

But since yesterday's posting I've realized a few things.

One is that I'm habituated to committing as a form of backup, but that isn't
necessarily a good thing.  rsyncing my working repo somewhere probably makes
more sense.

Second is that if I want to collapse history and avoid a merge changeset it
looks like I can do that pretty effectively with MQ, though I haven't tried
it yet.  Certainly MQ seems to fit my tendency to work in small increments.

Third is that I don't seem to be the only one asking for something like
this, so help is likely on the way, er, in development.

Thanks all.

Matt

On Tue, Jul 29, 2008 at 6:53 AM, Benoît Allard <benoit at aeteurope.nl> wrote:

> Matthew Moore wrote:
>
>>
>> What I would like to do is push JUST the changeset that was the result of
>> the merge up to the central repo, and NOT all my interstitial branch work.
>>  However when I "push -r" (or "pull -r" from the central repo) with the
>> revision of the merge changeset, all my branch changesets follow (reasonably
>> so, I'm presuming Mercurial needs to reconstruct the parent chain).  But I
>> want to keep the central repo "clean" of these details.
>>
>
> It seems  to me as if you were wanting to create a linear history out of a
> branched one. Do you have good reasons to want so ? Mercurial can deal
> really cleanly with divergent and re-merged branchs of development. There
> are plenty (and counting) of tools to visualize the development tree.
>
> You might achieve what you are looking for by generating an export of the
> merge changeset generated with the right parent (--switch-parent might be
> usefull depending on on which head you were when you made the merge) then
> import the exported diff ...
>
> -- Oups, actually making some testes in that direction, I end up with a
> traceback during importing ...
>
> ,---[traceback on import of a merge result]------
> |$ hg --traceback import patch
> |applying patch
> |Traceback (most recent call last):
> |  File "/Library/Python/2.5/site-packages/mercurial/dispatch.py", line 45,
> in _runcatch
> |    return _dispatch(ui, args)
> |  File "/Library/Python/2.5/site-packages/mercurial/dispatch.py", line
> 364, in _dispatch
> |    ret = _runcommand(ui, options, cmd, d)
> |  File "/Library/Python/2.5/site-packages/mercurial/dispatch.py", line
> 417, in _runcommand
> |    return checkargs()
> |  File "/Library/Python/2.5/site-packages/mercurial/dispatch.py", line
> 373, in checkargs
> |    return cmdfunc()
> |  File "/Library/Python/2.5/site-packages/mercurial/dispatch.py", line
> 356, in <lambda>
> |    d = lambda: func(ui, repo, *args, **cmdoptions)
> |  File "/Library/Python/2.5/site-packages/mercurial/commands.py", line
> 1547, in import_
> |    p2 = repo.lookup(p2)
> |  File "/Library/Python/2.5/site-packages/mercurial/localrepo.py", line
> 449, in lookup
> |    n = self.changelog._match(key)
> |  File "/Library/Python/2.5/site-packages/mercurial/revlog.py", line 828,
> in _match
> |    r = self.rev(node)
> |  File "/Library/Python/2.5/site-packages/mercurial/revlog.py", line 522,
> in rev
> |    raise LookupError(node, self.indexfile, _('no node'))
> |LookupError: 00changelog.i at 484ec10abbdc: no node
> |abort: 00changelog.i at 484ec10abbdc: no node!
> `-------------
>
> An alternative then (which works) is to use patch(1) and the exported
> patch, and then commit.
>
> Regards
> Benoit
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20080729/cd60f41d/attachment.htm 


More information about the Mercurial mailing list