Workflow problem resulting in useless commit messages

[Ben Finney]

"Andrew King" <eurokang at gmail.com> writes:

> I then try and keep up to date with trunk, because I want to have as
> few conflicts as possible in the long term. So, I have to use bzr
> merge, resolve conflicts, then commit. Commit message is usually
> "Merged from trunk". Repeat this a number of times.

That's the right way as I understand it. (Note that I'm merely an
enthusiastic user, and have been known in the past to get some of
these same things wrong.)

> I don't use pull, because then I have not committed my work, and if
> I get some complicated conflicts that I dont' resolve correctly the
> first time, I am in danger of losing my work.

Moreover, using ‘pull’ incorrectly alters the history of the current
branch such that it becomes another mirror of ‘trunk’. You are correct
to avoid it for a ‘feature-X’ branch.

> Then, I am done with the feature. I want to push to trunk. I use bzr
> push.

I think ‘push’ is to be avoided just like ‘pull’, for the same reason:
both commands are used when you want to maintain a mirror, not a
divergent branch.

Instead, you should merge into the ‘trunk’ branch from the ‘feature-X’
branch. That way the history in each correctly reflects how both of
them developed over time.

> I now end up with a nested commit tree, where I am responsible for
> all the changes that have been done since I started feature X.

That doesn't seem to match what you show for your example:

> ie.
> 
> revno something
> committer: me
> adding feature X.
> 
>      revno blah merged from trunk
>      committer: me
> 
>          revno blah
>          committer: someone else
> 
>           revno: blah
>           committer: yet someone else
>           some other feature
> 
>     revno blah
>     committer: me
>     some work on featureX

Note that the nested revisions (those that were merged from ‘trunk’)
do *not* have ‘me’ as the committer, but other people. That matches
the truth, doesn't it?

> What are we missing? This has to be a pretty common workflow, but
> there doesn't seem to be a clear way to support it.
> 
> should we be using bzr send or something instead of push?

For maintaining branches as divergent, use ‘merge’ in both directions,
with ‘resolve’ after resolving conflicts and ‘commit’ to commit the
merge.

Use ‘pull’ and/or ‘push’ to maintain branches as mirrors with
identical history.

> should we be using rebase or something?

I've never seen the appeal of ‘rebase’ (as I understand it, it munges
the history of a branch after the fact, which seems anathema to a
version control system's purpose), and certainly never needed to use
it.

-- 
 \     “The trouble with the world is that the stupid are cocksure and |
  `\             the intelligent are full of doubt.” —Bertrand Russell |
_o__)                                                                  |
Ben Finney