Hi,
On Wed, 20 Sep 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
>... 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
-
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