Junio C Hamano <gitster@xxxxxxxxx> writes:
> Sergey Organov <sorganov@xxxxxxxxx> writes:
>
>> Junio C Hamano <gitster@xxxxxxxxx> writes:
>>
>>> Sergey Organov <sorganov@xxxxxxxxx> writes:
>>>
>>> But the point is, if M and N are equally well tested before
>>> publication, they may still have bugs resulting from subtle
>>> interactions between A and F..X that is not discovered during that
>>> testing. And N loses the information that would help diagnosing
>>> what went wrong, which does not happen if you published M.
>>
>> I see your point.
>>
>> My point is that it's still a /choice/ between more information and
>> history simplification.
>
> I actually fail to see that point.
I'm sorry you do. Let me try again.
>
> If we are not constrained by that "first merge of a topic must be a
> redundant fast-forward merge", a topic that originally had two
> commits A and B, merged to the mainline to produce M and then
> further corrected with a commit C before it gets merged back at O to
> the mainline would leave this history:
>
> A-----------B-------C
> / \ \
> o---F---o---o---X---M---o---O---
>
> If you enforce the "first merge of a topic must be a redundant
> fast-forward merge" rule, you'd end up with a history like this:
>
> A-----------B
> /
> o---F---o---o---X-------N---o---P---
> \ / /
> A'--B'------C
>
> Is the latter materially simpler than the former? I do not think
> so.
I think it is. To see it clearly, let's cut common parts, and then cut
irrelevant parts as well from the pictures you gave:
A-----------B
/ \
o---F---o---o---X---M
---X-------N---
\ /
A'--B'
There is both qualitative and quantitative difference here.
1. The qualitative difference.
In the former case we have outdated topic branch and a merge commit that
simultaneously serves two purposes: gives a recipe to bring outdated
branch up to date, and records the fact that the topic in now merged to
mainline.
In the letter case we have up to date topic branch and a merge commit
that servers exactly one one purpose: it records the fact that the topic
in now merged to mainline.
This is exactly the "material" part of the simplification I mean.
2. The quantitative difference.
In the latter case the horizon to reason about the topic branch and its
adoption to mainline is at commit X, while in the former case it is at
commit F.
The quantitative difference that we have here is proportional to the
size of diff between X and F, and once we aim at decreasing this
difference (i.e., not accepting very outdated branches), it's only
logical to get rid of this difference entirely, once again ending up
with the latter case.
Finally, please also notice that ability to reference outdated version
of the topic branch (or even multiple of them), provided there is actual
reason to, is still there:
$ git checkout topic
$ git pull --rebase
$ git merge -s ours topic@{1} # keep reference to original
$ git checkout mainline
$ git merge --no-ff topic
> I was preparing myself to say "we rejected the combination because
> it would encourage wrong workflow, but perhaps over the years people
> like you and usbuser may have found good use patterns different from
> what we considered back then, and these use patterns may not
> encourage wrong workflows. It may not be a bad idea to introduce a
> new optional behaviour if that is the case", but what I heard so far
> does not convince me that we have good use patterns.
>
>>> About the docs easily getting misinterpreted, I think Elijah covered
>>> it pretty well.
>>
>> Yeah, sure, the docs should better be fixed.
>>
>> Anyway, bare "git --no-ff" is still there, and I can live with no safety
>> belt that '--ff-only' could easily have been, it's just that it's a pity
>> to see lost opportunities in the design.
>
> Lost opportunities to add an option to encourage bad workflow?
>
> No, thanks ;-)
I dunno what is that "bad workflow" you have in mind, sorry.
-- Sergey
