[Kde-scm-interest] Re: Usage of pull rebasing and merges

[John Tapsell]

merge>On 9 February 2011 07:50, Johannes Sixt <j.sixt at viscovery.net> wrote:
> The second drawback has to do with efficient testing, and it is much more
> serious, IMO. When you make a series of changes, you are expected to
> ensure that each individual change is self-contained and passes tests.
> I.e., after N commits, you have run N tests, at least. When you rebase
> this series on top of a new upstream, you have to run another N tests
> because you have N new commits. OTOH, when you merge, you have to run only
> *one* test.

If you are writing a long series of patches, then there is a good
chance that you made a mistake in one of the patches, and thus need to
fix it up.  At that point you should probably rebase anyway to squash
the fix and the original patch together, thus you need to retest all
the commits anyway.

John