[RFC][PATCH] New options to choose fast-forwarding on merge.

[Jan Hudec]

On Tue, Nov 21, 2006 at 10:03:27AM -0500, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jan Hudec wrote:
> > On Mon, Nov 20, 2006 at 12:45:18PM -0500, Aaron Bentley wrote:
> 
> >>There were two reasons:
> >>1. consistency: It's simpler to say "you never need to commit after a
> >>pull, you always need to commit after a merge".  Saying "If pull falls
> >>back to a merge, you need to commit" is messier.
> >>
> >>2. mirroring: I do 'bzr pull' in a mirror of bzr.dev, it should never
> >>report "branches are diverged".  If it does, I must have screwed up and
> >>committed to my local bzr.dev mirror.  Falling back to merge isn't
> >>helpful here; I want an error.
> > 
> > 
> > That's why I did merge --pull and not pull --merge.
> 
> For 1, the same inconsistency argument applies to "merge --pull" as
> "pull --merge".
> 
> And as I noted, 2 is weaker these days.  So I don't think these are good
> arguments in favour of your choice.

I don't see it as weaker. For me, 'I want that branch if I don't leak
any revisions' is a useful command ("leak", because they are not really
destroyed, only a "pointer" (a branch having them in history) to them is
lost).

> > pull, defined informally as 'update this to be copy of that branch' does
> > not make sense to have --merge option.
> 
> Ah, but I do want pull --merge, much more than I want merge --pull.
> Every now and then I want to merge in a non-mirror, but I never ever
> want to pull in a non-mirror branch.

There is a difference in what we consider important features of pull and
merge. When I do a merge, I simply want to get something with all local
and all remote changes. If the remote already has all local changes,
than remote suits my needs, so I want to pull it instead.

I don't care about anything like 'local view of history', so for me pull
does not do anything merge would not do. In fact in all cases where pull
works I consider the 'remote view of history' more correct:
 - If local is a leftmost ancestor of remote, than falling back to pull
   will just give me more than one revision in the leftmost ancestry.
   That makes no difference.
 - If local is non-leftmost ancestory of remote, than my previous
   changes were already merged into some "more mainline" branch and I
   now base my further changes on that merger (plus maybe some more
   changes). That's IMO what actually happened and so I want my view of
   history to start reflecting that.
So I do never ever what to do 'bzr merge', I always what to do 'bzr
pull||bzr merge'. That's why 'bzr merge --pull' (among other things
because I would immediately do:
  [aliases]
  merge=merge --pull
which looks slightly better than
  merge=pull --merge
).

> > On the other hand merge, defined informally as 'get changes from there
> > over here' does make sense to have an option to not create new revisions
> > if it's not necessary
> 
> When we decided to make pull rewrite the history, instead of merely
> appending to it, we were deciding against using pull as a merge tool.
> 
> The old pull did not throw away the local view of history.  The new pull
> does, and I don't think people expect *any* merge option to cause their
> local view to be lost.  Even if we did provide it, I would think we
> would need provide a way for people to undo it.

I personally see the change from appending to overwriting
revision-history as removing of concept of 'local history' altogether.
The view of history now only depends on the revision you are looking
from.

I don't agree with git folks that the parent ordering does not matter --
the first parent is the one that whoever did the merge considered "more
mainline" -- but IMO the way bzr pull overwrites 'revision-history'
properly reflects that. On the other hand the trivial merge would in
most cases (but not all cases -- that's why I don't actually want to
disable trivial merges like git does) not reflect that.

--------------------------------------------------------------------------------
                  				- Jan Hudec `Bulb' <bulb at ucw.cz>