Why I prefer rebase to merge. Is there a better alternative?

[Gioele Barabucci]

This happens to me quite often.

I have a main branch "mainline" and I branch "feat1" from it. I make some 
changes in feat1 and, when I am read to propose feat1 for integration into 
mainline, I bzr merge the latest mainline into feat1. At this point I 
usually find some problems that take some days to be resolved. By the time 
I'm ready to propose feat1 again, mainline has changed and I have to bzr 
merge another time; luckily this time the merge does not produce any 
conflict and I can bzr merge feat1 into mainline.

Result: mainline's history contains a merge that contains two (unneeded?) 
merges and only one commit with the (little) feature. I do not like this: 
bzr is recording in feat1 two merges that I did because I *had to*, not 
because I intended to do them (by contrast I *intended* to merge feat1 into 
mainline). I think that the fact that a branch is synchronized with its 
parent and how many times that synchronization is performed is just an 
"implementation detail", not something meaningful to the development and 
thus should not be recorded, at least not always.

This is why I use rebase instead of merge. Rebase performs this 
synchronization without recording anything and without "polluting" the 
history.

I understand the implications of rebase (history-rewriting is generally bad 
and hinders additional development on top of branches where it is used) but 
I think that merge, at least as it works now, is being used for two 
different functions, one of which is wrong (synchronizing before proposing).

Maybe what is needed is another version of merge: this new merge would do 
whatever is needed to keep they history in sync without "polluting" the log 
and the history with unintended merges.

Does anyone share my feeling about merge? Are there better workflows that 
can be used to obtain the same result without implementing a new kind of 
merge?

-- 
Gioele Barabucci <gioele at svario.it>