From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 18 Sep 2009 23:05:59 GMT
Subject: Re: merge ignores --no-commit in fast-forward case
Message-ID: <7viqff97l4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090918194717.GA18999@dr-wily.mit.edu>

Greg Price <price@ksplice.com> writes:

> Suppose we were to make such a change in 1.7.0 or a later version.
> What would the transition plan need to accomplish?  For instance,
> we could print a warning every time 'merge --no-commit' does a
> fast-forward, and make the change in a later version -- might that
> suffice?

I guess so, but right now I don't want to (nor have bandwidth to) think
about things beyond the release we are currently in pre-release freeze
for.  Helps from other people's braincells are very welcome.

> From: Greg Price <price@ksplice.com>
> Date: Fri, 18 Sep 2009 15:34:19 -0400
> Subject: [PATCH] Document behavior of --no-commit on fast forward.
>
> This behavior can be surprising, so document it.

If "surprising" is the problem (and it certainly is), perhaps it would be
better to rewrite it not to be so surprising, like:

        --no-commit::
                Do not create a new commit.  If your current branch
                fast-forwards to the branch you are merging, this option
                has no effect (use --no-ff for that).  Otherwise, a merge
                is done and the index and the work tree files are updated,
                but the command stops before creating a new commit that
                records the result, in order to give the user a chance to
                inspect and tweak the merge result before committing.

I dunno.

> Signed-off-by: Greg Price <price@ksplice.com>
> ---
>  Documentation/merge-options.txt |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/merge-options.txt
> b/Documentation/merge-options.txt
> index adadf8e..6015e5d 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -31,7 +31,10 @@
>  --no-commit::
>         Perform the merge but pretend the merge failed and do
>         not autocommit, to give the user a chance to inspect and
> -       further tweak the merge result before committing.
> +       further tweak the merge result before committing.  If the
> +       merge resolved as a fast-forward, the branch pointer will
> +       be updated as usual; --no-ff can be combined with this
> +       option to always preserve the branch pointer.