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

[Gioele Barabucci]

John Arbash Meinel wrote:
>> This is why I use rebase instead of merge. Rebase performs this
>> synchronization without recording anything and without "polluting" the
>> history.
> 
> It doesn't really. You still have to resolve the conflict. It just
> happens that now you are throwing away what you used to have, and
> replacing it with something that looks conflict free.
Well, not exactly. Maybe, if I branched mainline just half an hour later, 
the conflict would not be there. Suppose you branch feat1 from mainline 
while mainline contains an off-by-one error. You miss that bug and code+test 
your feature so that everything works fine (obviously your feature contains 
another bug but you do not know that). Few minute after you branched your 
branch the off-by-one error gets corrected. Now, when you merge (with no 
file conflicts: the fix is in a file you did not modify) your test 
infrastructure will tell you that you are failing some tests. You go ahead 
and solve your bug. Now, is the fact that you merged important? As you said, 
it is a matter of personal taste; I do not think it is important to have it 
recorded.

> Almost always these come down to personal preferences. I went through
> something where I wanted "nice discrete patches" for review, and did so
> without using rebase, etc.:
> http://jam-bazaar.blogspot.com/2009/10/refactoring-work-for-review-and-
>keep.html

I already read your article but I think your situation is a bit different:  
you are trying to separate a single line of development into multiple lines.  
I am oriented towards a single line of development branched off a  main 
branch. I also read the Tim Penhey's article you links: that workflow  is 
more similar to the scenario I have in mind. Yet he has to jump through 
hoops to get almost exactly the same result he would get with a rebase (and 
this bug fixed: https://bugs.launchpad.net/bzr-pipeline/+bug/450828).

> However, I would generally say "if a merge actually provides no benefit,
> 'bzr revert' it". Otherwise IMO it *does* provide information. It shows
> that something happened (I brought in more features from trunk, I
> resolved conflicts with trunk, etc.)
What if the merge brought in some unrelated feature? Why should such a merge 
annotation be part of the bundle I send upstream? What if the merge brought 
in a 2000% speed-up in the testing infrastructure? Should I keep developing 
without it? Or should I commit that merge, "polluting" the history?

In general, why should upstream be interested in *when* I started developing 
something? I understand that there are cases when this is desirable (for 
example DaggyFixes) but this is not always the case. And I think that in the 
long run, bigger projects will suffer from the complex tangled web of 
revisions that merge creates when it is not used to /merge/.

Couldn't we have a merge or a sync command that ingeniously move things  
around preserving all the commit information while giving the users a 
rebase-style history?

-- 
Gioele Barabucci <gioele at svario.it>