git-flow-release finish and --no-ff: why no-ff?

[cybertoast]

Why does the cmd_finish do the following - specifically the --no-ff line?

if ! git_is_branch_merged_into "$BRANCH" "$MASTER_BRANCH"; then
    git checkout "$MASTER_BRANCH" || \
      die "Could not check out $MASTER_BRANCH."
    git merge --no-ff "$BRANCH" || \
      die "There were merge conflicts."
      # TODO: What do we do now?

What this causes is for a "git flow release finish" to create a new commit once it's done, irrespective of whether the merge was "clean" or not. The problem with this is with the tag that's created, and what it points to. If the develop commit is unchanged (ie no merge conflicts) when the release is merged into master, the tag should point to the same commit. This would ensure that anyone looking up the commit by the tag gets exactly the same code, and does not need to see what was merged from develop into master.

It's possible that there's some rationale here that I have not thought about. If so could someone please enlighten me? I feel that the correct code is:

if ! git_is_branch_merged_into "$BRANCH" "$MASTER_BRANCH"; then
    git checkout "$MASTER_BRANCH" || \
      die "Could not check out $MASTER_BRANCH."
    git merge "$BRANCH" || \
      die "There were merge conflicts."
      # TODO: What do we do now?

(no --no-ff). Thanks.

[havvg]

The --no-ff flag encourages git to add a merge commit even if the merge could be done with a fast-forward. The advantage of doing so is to revert the merge. For further and more detailed information, see http://www.kernel.org/pub/software/scm/git/docs/howto/revert-a-faulty-merge.txt

[MariposaGentil]

Is there any philosophy on why git-flow doesn´t provide a way to ff the merges? Is this open to PRs? In my case, as I'm releasing a branch, I won't ever want to revert a whole merge, but a single feature-commit of that bunch