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

From: Nanako Shiraishi <[email-masked]>
Date: Thu, 22 Oct 2009 19:21:45 +0900

Quoting Junio C Hamano <[email-masked]>

> 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 <[email-masked]>
> ---
>
>  * 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/