Re: [RFC/PATCH] git-merge: implement --ff-only-merge option.

[Sergey Organov <sorganov@gmail.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Sergey Organov <sorganov@gmail.com> writes:
>
>> This option allows to create merge commit when fast-forward is
>> possible, and abort otherwise. I.e. it's equivalent to --ff-only,
>> except that it finally creates merge commit instead of
>> fast-forwarding.
>>
>> One may also consider this option to be equivalent to --no-ff with
>> additional check that the command without --no-ff  would indeed result
>> in fast-forward.
>>
>> Useful to incorporate topic branch as single merge commit, ensuring
>> the left-side of the merge has no changes (our-diff-empty-merge).
>>
>> Signed-off-by: Sergey Organov <sorganov@gmail.com>
>> ---
>
> The workflow this implements sounds like "because we can", not
> "because it will help us do X and Y and Z".

Well, I do have full time job, and while I think I can instantly invent
quite a few things from the "because we can" camp, I usually don't.

> Why would it be useful to limit the history to a shape where all
> merges are the ones that could have been fast-forwarded?

Except by true merge, how else can I express with git that 'n'
consequitive commits constitute single logical change (being originally
some topic branch)? Now I just want such special kind of merge to be
entirely trivial merge on one side. i.e. perfectly clean merge every
time.

Moreover, as topic branches are usually rebased before merge anyway,
why shouldn't I have simple capability to enforce it?

> I cannot justify that sensibly myself, which in turn makes the
> feature smell to me that it is encouraging a wrong workflow.

What's wrong, exactly, in enforcing rebasing of topic branches before
merge? Basically, I need --ff-only, only I don't want git to forget that
this entire set of commits is logically single unit. Neither do I want
to loose the structure of commits that --squash offers.

-- Sergey.