From: Nanako Shiraishi <nanako3@lavabit.com>
Date: Thu, 22 Oct 2009 10:21:45 GMT
Subject: Re: [RFC/PATCH] git-merge: forbid fast-forward and up-to-date when --no-commit is given
Message-ID: <20091022192145.6117@nanako3.lavabit.com>
In-Reply-To: <7vpr8g1l2a.fsf_-_@alter.siamese.dyndns.org>

Quoting Junio C Hamano <gitster@pobox.com>

> 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 <gitster@pobox.com>
> ---
>
>  * 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/