Cross-project merges

[Andrew Bennetts]

First, a correction on my earlier post:

> > First, there's the trivial: join doesn't work with 2a either, for
> > similar reasons to why merge-into doesn't work.  (It expects to be able
> > to mutate inventory._byid).

I was wrong on this point.  Sorry if I alarmed anyone!

The inventory in question is essentially the result of
WorkingTree.open_containing(...)[0].inventory, and is an Inventory
rather than CHKInventory.  Ideally I think the subsume method would
still avoid mutating _byid, which AIUI ought to be treated as private to
inventory objects.

Aaron Bentley wrote:
[...]
> > Second, join works in terms of trees on disk.  You can't use join with a
> > remote branch the way you can use merge.
> 
> I don't think that's a big difference.  You need to have a working tree
> for merge-into or for join.  The only difference is that with join, you
> need get a local tree for the remote branch explicitly, whereas
> merge-into creates it as part of the merge.

Yes, that's exactly what I meant.  I think that's a pretty nice thing
to support in a single command, though, especially considering the next
point...

> > Third, join works with whole trees, but there are use cases for partial
> > merge-intos (somewhat like there are uses for partial merges).
> 
> You always need to have a whole tree at the end.  If you only want to
> join part of the tree, you can extract that part using "split".

That's a lot more awkward than a single command, though.

And along those lines, if you want to join a specific revision other
than tip, you could assemble that tree too... but I've been thinking
that it would be reasonable to add --revision argument to 'merge-into',
just like most of our other commands do.  (The bzrlib APIs behind
merge-into already support specifying a revision.)

Conceptually, I like that it is a kind of merge, that could specify a
revision, can produce conflicts, and can fetch and link history and tags
(and not use history if it is a partial merge).

I'm far from sold on the UI I have for 'bzr merge-into' at the moment,
especially the name 'merge-into'.  I've been making the UI mainly as a
sanity check for the underlying APIs.

But what I do like about the UI is that it provides a pretty simple way
to express both 'incorporate that branch (remote or local) into this
tree' and 'combine just a particular subdirectory from that branch in
this tree, and call that subdirectory "foo"', which is nice.  The UI of
cmd_merge_into also corresponds well the bzr-builder patch I have to add
that facility there, but that's not a big deal.

I am attracted to the idea of updating 'bzr join' to provide these
features instead of making a yet another command, but I think it could
easily detract from join's UI for its current use cases.  What do you
think?  I'll experiment a little and see how it turns out.

Perhaps my patch should have merge-into has a hidden command.  Or have
no command at all, and just leave the bzrlib plumbing, and then the UI
can live in a separate plugin until we're confident we have it right (or
that we don't want it).

At an API level, I think the basic capability belongs in bzrlib, where
other tools like bzr-builder can make use of it.

-Andrew.