Re: [PATCH/RFC 1/2] pull: pass the --no-ff-only flag through to merge, not fetch

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 1, 2011, 04:58 UTC
Message-ID: <7vborsq45x.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1322703537-3914-1-git-send-email-naesten@gmail.com>

Samuel Bronson <naesten@gmail.com> writes:

> Without this, pull becomes unusable for merging branches when the config
> option `merge.ff` is set to `only`.
>
> Signed-off-by: Samuel Bronson <naesten@gmail.com>

I wonder why you need this. We have "git config --unset merge.ff" after all. From purely mechanstic point of view, being able to temporarily defeat a configuration variable makes perfect sense, but from the point of view of workflow, I am not sure if it is a good thing to even allow it in the first place in this particular case.

Setting merge.ff to 'only' means you are following along other people's work and making nothing new on your own in this particular repository, no? Hence you won't be asking the upstream to pull from this repository, which in turn means that even if you made a merge by temporarily defeating the configuration setting with this patch, your future pulls will no longer fast forward, until somehow the upstream gets hold of your merge commit.

By the way (this is a digression), I also have to say --no-ff-only is too *ugly* as a UI element, even though I know "git merge" already allows it by accident.

"ff" is a tristate. By default, fast-forward is done when appropriate, and people can _refuse_ to fast-forward and force Git to create an extra merge commit. Or if you are strictly following along, you can say you _require_ fast-forward and reject anything else. So it may make the UI saner if we updated the UI to allow users to say:

	--ff=normal	the default
        --ff=never	same as --no-ff that forces an extra merge commit
        --ff=required	same as --ff-only

while keeping the current --ff-only and --no-ff as backward compatibility wart.

I dunno.