Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given

Quoting Junio C Hamano [off-list ref]

Traditionally "git merge --no-commit" meant just that: do not create a new
commit even when a merge succeeds.  But this leads to confusion when the
merged commit is a descendant of the current commit, in which case we
succeed the merge by fast-forwarding and without creating a new commit.
Also when the merged commit is already a part of the history, we succeeded
without doing anything.

Error out when --no-commit is given but the merge would result in a
fast-forward or an up-to-date.

Signed-off-by: Junio C Hamano <redacted>
---

 * This is the first alternative.  I think it makes more sense than the
   other one, but I am unsure, as I obviously do not get confused when
   --no-commit becomes no-op due to a fast-forward nor an up-to-date and
   am rather happy with the current behaviour.

I think this is good (but I am saying this only from your 
description without understanding the updated code), but 
the change breaks --squash to merge a branch, doesn't it?

    % git checkout feature  # from your master branch
    % work; git commit; work; git commit
    % git checkout master  # go back to your master branch
    % git merge --squash feature

This is a useful way to clean up changes that were built
in small steps that turned out to be worth only a commit.

-- 
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/