merge vs pull (was What we did at UBZ)

[Erik Bågfors]

2005/11/21, Martin Pool <mbp at sourcefrog.net>:
> On 21 Nov 2005, James Blackwell <jblack at merconline.com> wrote:
> > > Aaron:
> > > If it's a merge, you won't be able to pull.
> >
> >
> > Of course... this is all a moot point if merge and pull are the same
> > command. The user wouldn't be the wiser. :)
>
> Sure, but that gets into a whole other bunch of issues previously
> discussed.  Most importantly, after a merge, you need to commit.  I
> don't want to give that up, because being able to review/test/edit the
> merge results is important to maintaining user control on what goes
> into a branch.
>
> Conversely, we want to be able to track another branch without
> generating a lot of new commits, which implies some kind of
> pull/mirror/sync thing.

I was thinking of this scenario.

Say I find a bug in bzr, I create my branch and fix it.  You are all
so lazy that it takes two months to pull from me (just kidding, that
would never happen :) ).  I'd like to keep my own three in the
meantime.   This means I have to merge and commit now and then.  Since
the fix was trivial, there are no conflicts, so I just "bzr merge; bzr
ci -m merge' now and then.

What I would like to be able to do instead is to keep my commit(s) in
the tip (to speak hg talk).  So, say I branch and get revno 1..2000. 
Now I commit revno 2001.  Next time I pull you have done 10 more
commits.  What I'd like to be able to do is make 2001..2010 be your
revisions and my revision that was numbered 2001, will not be 2011. 
As long as there are no conflicts at least.  Basically, undo, pull,
redo.

Once you merge my stuff, I'm happy with the history not being exactly
the same as long as I can get to pulling again.  But to make a small
change and keep up to date with upstream should be simple.

The bound branch implementation does something magical like this when
you rebind to a branch again.

/Erik