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

[Andrew Bennetts]

Gioele Barabucci wrote:
[...]
> 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.

One point here is how likely is it that you introduced a bug in the process of
merging?  This can happen by resolving a conflict incorrectly, or from having an
apparently non-conflicting merge introduce a failure that isn't noticed by
tests, or by forgetting to run tests.

If you rewrite history so that it always looks like the code was like that, you
now have a branch that always had that bug.  You've lost information about when
it really happened.

If you record it as a merge, then you can see that it is the merge that
introduced the bug.

Does that the difference matter?  Probably not often; I find that most branch
history is pretty much write-only, people rarely look back on it unless
something has gone wrong (or if they are compiling statistics).  This is
especially true for non-mainline history.  But my personal preference is that
when something does go wrong, and I want to understand why, I'd rather have the
most accurate picture of what happened, rather than a faked one.

Note that even if you do a rebase where you confirm the results are good by
running the full test suite for every newly synthesised revision you can still
have this problem because you may have introduced a bug that the current test
suite doesn't notice.  But with a good enough test suite it would presumably
catch a large fraction of problems.

[...]
> In general, why should upstream be interested in *when* I started developing 
> something? I understand that there are cases when this is desirable (for 

Actually, I think that's good data to preserve.  It's often interesting and
useful to know how long branches take to develop, so you can try to improve
bottlenecks in your development process.  (Is there a long gap between branch
finished and branch landed?  etc.)

I agree that often this extra will be basically ignored, but at the same time
the cost of preserving it is minimal.  Note that how you present changes to
upstream for review is a separate issue to what the branch history looks like!

-Andrew.