Bound branch implementation

[Nathaniel McCallum]

On Sun, 2005-11-13 at 19:52 +0100, Jan Hudec wrote:
> On Sun, Nov 13, 2005 at 05:09:17 -0500, Nathaniel McCallum wrote:
> > Call me crazy (feel free to do so), but let me brainstorm for a second.
> > What about this?  It seems more consistent and it lessens (by one) the
> > top level command namespace (which is already overcrowded).  Basically,
> > I'm introducing the idea of "shadow" branches which we can push changes
> > to or sync with (bi-directional).
> > 
> > * change the syntax for merge to:
> >  - bzr merge <from_URI> <to_URI>   (merge two arbitrary branches)
> >  - bzr merge -t|--to <URI>         (does: "bzr merge ./ <to>")
> >  - bzr merge -f|--from <URI>       (does: "bzr merge <from> ./")
> >  - bzr merge -u|--update [<URI>]   (does: "bzr merge <URIparent> <URI>")
> >  - bzr merge -s|--sync <URI> <URI> (performs a bi-directional merge)
> >  - bi-directional merges do "bzr merge <a> <b>" then "bzr merge <b> <a>"
> >  - refuse merge if any uncommitted changes in any related branch
> >  - handle conflicts like a normal commit.  ie:
> >    $ bzr merge -s ./ /foo
> >      > There are conflicts!  Fix them, commit them, then re-merge...
> >    <fix conflicts>
> >    $ bzr commit -m "fixed merge conflicts"
> >    $ bzr merge -s ./ /foo
> > * drop pull (use "bzr merge --update")
> 
> It's *NOT* true.
> 
> > * drop push (use "bzr merge --to /foo")
> 
> Neither is this.
> 
> pull/push only propagate the changes that are based on the target head. On
> the other hand merge propagates any changes and adds them as another parent
> for the next commit.

I think this is a false dichotemy.

> Follows from that that you can pull/push with uncommited changes (they will
> be rebased to the new head), but you should never merge then.

This is true for the current command merge, I'm trying to make us
rethink the whole concept of merging.

> Also the target of merge should always be required to be local, since you'll
> need to inspect and commit the result anyway.

I'm sure this can be worked around.

Nathaniel