Re: Fast-forward able commit, otherwise fail

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2016, 15:49 UTC
Message-ID: <xmqqeg6y7t62.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1mqa4a5.1ykwh5b8vc9q7M%lists@haller-berlin.de>

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

Show 5 quoted lines

> 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.