Pushing after merge considered harmful

[Martin Pool]

2010/1/26 Eli Zaretskii <eliz at gnu.org>:
>> Date: Tue, 26 Jan 2010 09:41:15 +0100
>> From: Martin Pool <mbp at canonical.com>
>> Cc: Alexander Belchenko <bialix at ukr.net>, bazaar at lists.canonical.com
>>
>> It means that you can only change the branch tip pointer from A to B
>> if A is in the left-hand history of B.  Left-hand history means the
>> history following only the 0th (left-hand) parent pointer; this means
>> essentially that you got from A to B by either simple commits or
>> commits that merge other things in, not by merging in A.
>
> Thanks.  What does this mean in practice, wrt commands such as
> "checkout", "commit", "update", "merge", "pull", and "push"?  Does the
> type of the branch (bound or not, lightweight or not) matter?

merge, checkout and update are readonly wrt the branch, so this is
irrelevant, as are all operations coming _from_ an
append_revisions_only branch.  It only affects trying to write to it.

Normal commits will succeed, because commit implicitly does a similar
check that the wt is appending one revision to the branch.  It may be
possible to contrive a commit situation that would be trapped by
a_r_o.

Essentially you can push to and pull onto an a_r_o branch only if the
revision you're trying to pull is descended from the current tip by a
straightforward series of commits based off that revision.

Another way to look at it: if append_revisions_only is set, the only
changes that will be allowed are those that mean 'bzr log' on the
branch before the operation is the tail of running 'bzr log' on the
branch afterwards.  You are not allowed to do operations that remove
revisions from the history, or that make things previously seen as
mainline then be seen as merged-in.

-- 
Martin <http://launchpad.net/~mbp/>