[MERGE] make 'push' default to parent branch

[Mark Hammond]

Following up more for my own understanding than anything else...

Robert wrote [but quoting out of order]:

> So for the use cases given, here is how I do the same thing:
> case 1) work directly on a remote branch I can write to
> bzr checkout lp:foo
> hack
> commit --local as needed
> repeat
> commit

That's interesting - I should play with that a little more.  My brief
reading left me with a concern I may accidently forget '--local' in some
cases, so this would be a good option if branching was not.  I probably need
to actually suck-it-and-see.

> case 2) work on a local branch for something I can write to
> bzr checkout lp:foo trunk
> bzr branch trunk local
> cd local
> hack & commit
> repeat
> cd trunk
> bzr update
> bzr merge ../local
> commit

Yeah, that does make a lot of sense and branching a checkout is something I
wouldn't have considered!  It takes a while to get your head around how
flexible things really are.

You started with:

> I have an observation to make here. I *very* rarely use push to
> integrate work.
> 
> I use push to maintain an exact mirror of a branch.

Both your workflows above involved working with checkouts, which is probably
where my misconception starts.  However, it seems some bzr docs
(http://doc.bazaar-vcs.org/bzr.dev/en/developer-guide/HACKING.html at least)
recommends making a local branch of the remote repository, then making
another local branch to do the work.

Am I correct in saying that if (and possibly only if!) you followed that
HACKING workflow, you *do* need to use "push" to integrate changes, and that
for many smaller projects, it is likely you will want to push to the parent
branch?  (Which isn't trying to make a case to change the default behaviour)
 
> I think the key thing driving this difference is that bzr logs
> in /topological order/. Neither git nor hg log in topological order.
> (And they don't log in the same order as each other). The behaviour of
> log alters what people look for in other commands to a surprising
> degree. I'm not 100% sure bzr has the best possible answer to log, but
> I
> am sure its better than answers git and hg have.
> 
> (git logs in topologically-constrained date order, which means you are
> not seeing what commits were done together, rather the concurrent
> activity in N branches that eventually got merged. This makes log very
> hard to follow).
> 
> (hg logs in 'insertion-into-repository' order, which is topologically
> constrained but unstable between developers of concurrent branches)

Interesting...

Thanks,

Mark