# Bug report: "git-merge --ff" should fail if branches have diverged 3 messages from 2012-02-22 to 2012-02-22. Participants: Sean Gies, Junio C Hamano. Thread: https://gitlist.dev/t/29697 ## Sean Gies, 2012-02-22 21:51 Subject: Bug report: "git-merge --ff" should fail if branches have diverged Message-ID: URL: https://gitlist.dev/e/DB0837FD-0963-4BF9-BD7B-B243F580CC1C%40imgtec.com ``` Git developers, I have a small bug report: When I specify the "--ff" option to git-merge, I expect it to perform a fast-forward merge or none at all. If the branches have diverged and a fast-forward cannot be done, I expect the command to fail. With git 1.7.6, if "git-merge -ff" cannot fast-forward, it falls back to creating the merge commit I did not want. Thank you, -Sean ``` ## Junio C Hamano, 2012-02-22 22:14 Subject: Re: Bug report: "git-merge --ff" should fail if branches have diverged Message-ID: <7vr4xm8qin.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vr4xm8qin.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Sean Gies writes: > When I specify the "--ff" option to git-merge, I expect it to perform a > fast-forward merge or none at all. That expectation needs to be adjusted with s/--ff/--ff-only/, I think. The "--no-ff" option says "Never do fast-forward and always create extra commit even when the side branch is a descendant", and the "--ff" option is a way to countermand it, i.e. "It is ok to fast-forward this merge". And there is another one "I do not want anything bug fast forward", and that is spelled --ff-only. ``` ## Junio C Hamano, 2012-02-22 22:27 Subject: [PATCH] Documentation/merge-options.txt: group "ff" related options together Message-ID: <7vmx8a8pxg.fsf_-_@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmx8a8pxg.fsf_-_%40alter.siamese.dyndns.org In-Reply-To: <7vr4xm8qin.fsf@alter.siamese.dyndns.org> ``` The --ff-only option was not described next to --ff and --no-ff options in "git merge" documentation, even though these three are logically together, describing one option that takes one of three values. Also the description for '--ff' and '--no-ff' discussed what '--ff' means, and mentioned '--no-ff' as if it were a side-note to '--ff'. Make them into three top-level entries and list them together. This way, it would be more clear that the user can choose one from these three. Signed-off-by: Junio C Hamano --- * Perhaps a patch like this would be an improvement to make it easier to find the options. Documentation/merge-options.txt | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt index f2f1d0f..0bcbe0a 100644 --- a/Documentation/merge-options.txt +++ b/Documentation/merge-options.txt @@ -24,13 +24,18 @@ updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be set to `no` at the beginning of them. --ff:: + When the merge resolves as a fast-forward, only update the branch + pointer, without creating a merge commit. This is the default + behavior. + --no-ff:: - Do not generate a merge commit if the merge resolved as - a fast-forward, only update the branch pointer. This is - the default behavior of git-merge. -+ -With --no-ff Generate a merge commit even if the merge -resolved as a fast-forward. + Create a merge commit even when the merge resolves as a + fast-forward. + +--ff-only:: + Refuse to merge and exit with a non-zero status unless the + current `HEAD` is already up-to-date or the merge can be + resolved as a fast-forward. --log[=]:: --no-log:: @@ -65,11 +70,6 @@ merge. With --no-squash perform the merge and commit the result. This option can be used to override --squash. ---ff-only:: - Refuse to merge and exit with a non-zero status unless the - current `HEAD` is already up-to-date or the merge can be - resolved as a fast-forward. - -s :: --strategy=:: Use the given merge strategy; can be supplied more than ```