Re: [PATCH v4 3/7] revert: add --ff option to allow fast forward when cherry-picking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Christian Couder <chriscool@xxxxxxxxxxxxx> writes:

> From: Junio C Hamano <gitster@xxxxxxxxx>
>
> 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.
>
> Maybe this option could be made the default in the long run,

I never said that.

For scripted use, like we can see in your [PATCH 7/7], "cherry-pick --ff"
could be a good ingredient (but even then the calling Porcelain script may
already know that what is being picked is a direct descendent (rebase -i
certainly should, as the last commit it processed from the todo file is at
the HEAD), but for manual use case it just feels silly to assume that the
end user is so stupid that s/he doesn't know the commit being picked might
be a direct descendant, which would be the only reason why making --ff the
default might make sense.

And adding --no-ff and sprinkling that to scripts, only to support that
default change as a future possibility, feels doubly silly.

What was the real motive/use case of "cherry-pick --ff"?
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]