Re: Fast-forward able commit, otherwise fail

lists@haller-berlin.de (Stefan Haller) writes:

I have read and re-read this thread a hundred times now, but I still
don't understand why it makes much of a difference whether or not Bob
rebases his branch onto master before pushing his merge. In both cases,
Alice and Bob have this race as to whose push succeeds, and in both
cases you end up with merge commits on master that are not well tested.

One crucial difference is that at least you _know_ that $tip^2 has
been well tested, when you do not rebase, and you can check out
$tip^2 to study and understand how it was supposed to work, when the
merge of the topic into an updated mainline is found to be faulty.
That knowledge helps you to go forward--you'd need to adjust some
untold assumption $tip^2 made, which was broken somewhere between
$tip^2..$tip^1 on the mainline, to an updated reality.

Once you rebase, you end up with "This series of changes once was
working well, and during the rebase somewhere it stopped working",
unless you say something like "these 7 changes were originally
developed and tested on commit X" in the rebased commit.