Pushing after merge considered harmful

[Stefan Monnier]

Would it be possible to refuse a "bzr push" if it would change the
destination's history by changing the order of the ancestors?

Currently, if you do: "bzr merge <foo>; bzr commit; bzr push <foo>",
bzr will be happy to commit the local changes to <foo> and to cause
<foo>'s history to be modified in the sense that entries that used to be
in "bzr log" may be relegated to "bzr log -n2".

I think this is bad.  We've just had this happen to the Emacs
repository, and it's a pain in the rear.  I understand it can be
occasionally useful, but could you please change "bzr push" to avoid
this problem?

One option is to make "bzr push" fail in this case, with the option to
run "bzr push --force" in those cases where it's actually useful/needed.

Another option (that would be even better) might be to accept "bzr push"
but change it so that the leftmost revision is the one from <foo> rather
than the local one, so the history shown by "bzr log" is not messed up.
I'm not sure if this is possible, tho (depends on whether the order of
ancestors affects the revision's hash, I guess).


        Stefan