From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 05 Feb 2010 23:57:18 GMT
Subject: Re: [PATCH 5/9] revert: add --ff option to allow fast forward when cherry-picking
Message-ID: <7vpr4jnsm9.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100205231112.3689.67634.chriscool@tuxfamily.org>

Christian Couder <chriscool@tuxfamily.org> writes:

> As "git merge" fast forwards if possible, it seems sensible to
> have such a feature for "git cherry-pick" too, especially as it
> could be used in git-rebase--interactive.sh.


> +	if (!(flags & PICK_REVERSE) && ff_ok && commit->parents) {
> +		unsigned char head_sha1[20];
> +		if (get_sha1("HEAD", head_sha1))
> +			die("You do not have a valid HEAD.");
> +		if (!hashcmp(commit->parents->item->object.sha1, head_sha1)) {
> +			char *hex = sha1_to_hex(commit->object.sha1);

With this check, you are saying:

	If we are cherry-picking commit $C, and if the current HEAD is
        the first parent of $C, then just reset to $C instead of running a
        cherry-pick.

I didn't check if you have access to commit->parents->item->object.sha1 at
this point in the codepath, though (e.g. have you parsed "commit" yet?).

If the goal is to make untouched 'pick' in rebase-i to fast forward
without actually running cherry-picking, perhaps it is much cleaner to do
this kind of comparison in the caller of cherry-pick (i.e. rebase-i and
anything that runs cherry-pick)?

The whole series is titled as if "cherry-pick --ff" is the primary goal,
but I am puzzled why earlier patches in the series were necessary for this
change.