Re: [PATCH] add receive.denyNonFastforwards config variable

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Sep 21, 2006, 00:17 UTC
Message-ID: <Pine.LNX.4.63.0609210211570.19042@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7vlkoeds82.fsf@assigned-by-dhcp.cox.net>

Hi,

On Wed, 20 Sep 2006, Junio C Hamano wrote:

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	No longer barfs on new refs, and tries all merge bases (even if I
> > 	cannot come up with any scenario where there is more than one merge
> > 	base in the case of a fast forward).
> 
> Hmm.  If that is the case (and I think it is although I haven't
> come up with a proof),

>From git-fetch.sh:

            # Require fast-forward.
            mb=$(git-merge-base "$local" "$2") &&
            case "$2,$mb" in
            $local,*)
                if test -n "$verbose"
                then
                        echo >&2 "* $1: same as $3"
                fi
                ;;
            *,$local)
                echo >&2 "* $1: fast forward to $3"
                echo >&2 "  from $local to $2"
                git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
                ;;

So we indeed assumed that git-merge-base returns the old commit in the case of a fast-forward (git-merge-base returns just the first item of the result of get_merge_bases()).

Note that I have no proof that this assumption is true. It might be wrong in this case:

    X - a - b - c - Y
  /           /
o - d - e - f

where X is the old commit, and Y is the new commit. But I am too tired to test it right now.

Show 7 quoted lines

>... the test can be written like this:
> 
> 	if (bases && !bases->next &&
>             hashcmp(old_sha1, bases->item->object.sha1))
>         	; /* happy */
> 	else
>         	return error("not a fast forward");

Plus

	free_commit_list(bases);

as Jeff pointed out.

Ciao, Dscho