Working on several branches at the same time

[James Westby]

On Tue, 2008-06-17 at 00:58 +0900, David Cournapeau wrote:
> Now, to avoid this, I could do a pull. But then, the difference between 
> pull and merge would be whether I have one commit for the fixbug branch, 
> or several, which does not sound quite right (if I have several commits 
> in the fixbug branch, then no commit will be fix bug, but more detailed, 
> likely because the bug was big).
> 

The difference between whether you can do a merge or a pull isn't how
many commit you made on the fixbug branch, it's whether there have
been any new commits on mainline in the meantime.

If you are able to do a pull then the difference would just be in the 
log, as a pull would add more than one mainline revision. Then you 
wouldn't have the single "fix bug" merge entry hiding all of the other 
work.

> But the log is ugly:

That's quite a subjective thing, but the extra merge commits
are necessary in general if you don't want to rebase.

> > If you do not want these merge commits then rebase is the way to do it,
> > yes, but the merge commits shouldn't cause you any problems.
> 
> I was wondering whether it was possible to have the best of both words: 
> nice history, and "works at every commit" bzr behavior. Now that I think 
> about it, it sounds difficult, even antinomic ?

Do you mean "works at every revision on the mainline?"

It's possible to have that, but you are not only doing rebase operation,
but mutating revisions as you go, so there is more room for unexpected
behaviour.

Thanks,

James