Quoting Junio C Hamano <gitster@xxxxxxxxx>
> 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@xxxxxxxxx>
> ---
>
> * 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html