merge>On 9 February 2011 07:50, Johannes Sixt <[email protected]> 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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
