Re: Symmetric of rebase / more intelligent cherry-pick

Junio C Hamano [off-list ref] writes:

Lionel Elie Mamane [off-list ref] writes:

quoted

git cherry-pick ..UPSTREAM
*nearly* does what I want, except that it lacks rebase's intelligence
of skipping commits that do the same textual changes as a commit
already in the current branch.

I think in the longer term "--ignore-if-in-upstream" that is known only to
format-patch, which is the true source the intelligence of rebase you
observed comes from, should be factored out into a helper function that
can be used to filter output from get_revision() in other commands, or
perhaps get_revision() itself might want to learn it.

We actually have half of that filtering in "--cherry-pick" that was
introduced in d7a17ca (git-log --cherry-pick A...B, 2007-04-09).

Perhaps the recent cherry-pick that allows multiple commits to be picked
should use that option (i.e. a "log --cherry-pick --right-only ..@{u}"
equivalent) when coming up with which commits to apply?

Junio C Hamano wrote:

We actually have half of that filtering in "--cherry-pick" that was
introduced in d7a17ca (git-log --cherry-pick A...B, 2007-04-09).

Perhaps the recent cherry-pick that allows multiple commits to be picked
should use that option (i.e. a "log --cherry-pick --right-only ..@{u}"
equivalent) when coming up with which commits to apply?

No UI ideas from me, but I have a script like this sitting in $HOME/bin:

 base=$1 topic=$2

 git rev-list $base..HEAD |
 git diff-tree -s --pretty=raw --stdin |
 sed -ne 's/(cherry picked from commit \([0-9a-f]*\))/\1/p' |
 xargs git cherry-pick -x -s \
   --cherry-pick --right-only --no-merges HEAD...$topic \
   --not $base