Samuel Bronson <naesten@xxxxxxxxx> 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@xxxxxxxxx>
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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html