Christian Couder <chriscool@xxxxxxxxxxxxx> 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.
--
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