Bound branch implementation

[Jan Hudec]

On Sun, Nov 13, 2005 at 14:07:00 -0500, Nathaniel McCallum wrote:
> 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.

No, it's real. There are two distinct operations -- bringing over the changes
and merging revisions. These operations do make sense to make separately.
Since bzr only allows a single head, merge includes pull. But not vice versa.

> > 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.

It's not about a 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.

It can be worked around. But it *SHOULD NOT* be worked around. Merging
somewhere else than on your local working copy is usually not a good idea.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051113/036a2ae6/attachment.pgp