[PATCH] push to diverged branch

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthieu Moy wrote:
> Hi,
> 
> Trying to "bzr push" to a diverged branch, bzr says:
> 
> $ bzr push
> Using saved location: sftp://my.remote/branch/
> bzr: ERROR: These branches have diverged.  Try a merge then push with overwrite.
> 
> 
> Indeed, it's not necessary to use --overwrite after the merge, since
> the current revision becomes a successor of the tip of the branch to
> push to. I think it's a very bad idea to encourrage people to use this
> potentially dangerous option. I think the message should be fixed to
> something like:
> 
> === modified file 'bzrlib/builtins.py'
> --- bzrlib/builtins.py2006-09-27 12:50:58 +0000
> +++ bzrlib/builtins.py2006-10-07 13:22:24 +0000
> @@ -645,7 +645,7 @@
>                      count = tree_to.pull(br_from, overwrite)
>              except DivergedBranches:
>                  raise BzrCommandError("These branches have diverged."
> -                                      "  Try a merge then push with overwrite.")
> +                                      "  Try using \"merge\" and then \"push\".")
>          note('%d revision(s) pushed.' % (count,))
>  
>          if verbose:

+1 on the change. In the past, the check was only on mainline revisions
(it didn't check ancestry) so you did indeed have to supply --overwrite.

But as you notice, that isn't the case anymore.

I probably would change it to:

' Try using "merge" and then "push".')

Rather than escaping all the quotes.

> 
> (the quotes insist on the fact that they are command names)
> 
> (BTW, is "push --overwrite" really useful?)

As mentioned it used to be necessary. And at this point, it is still
useful to overwrite diverged branches with an explicit *this is what I
want*. Sort of a 'I know what I'm doing, let me do it' flag. While you
may lose some revisions in a history, you won't lose any data from the
repository, so it isn't really lossy (but not entirely lossless either).

> 
> Then, I got something funny (but IIRC this is a known bug):
> 
> $ bzr push
> Using saved location: sftp://my.remote/branch/
> -1 revision(s) pushed.
> $
> 

Yeah. Definitely a known bug. And the best recommendation I know of is
to split it so that we report the # of mainline revisions, and the # of
ancestral revisions. The second one should almost always increase, while
the first one will be accurate for someone who does 'bzr log' or 'bzr
revno'.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFKEM7JdeBCYSNAAMRArl7AKCHrRTz1r5f4FYGvOVqn3K+yLjSYACfY3vM
7GN4Fmov9Z1oUrauwmLfpsE=
=U45R
-----END PGP SIGNATURE-----