git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Symmetric of rebase / more intelligent cherry-pick

From
LMLionel Elie Mamane <lionel@mamane.lu>
Date
Oct 11, 2011, 15:54 UTC
Message-ID
<20111011155444.GB14417@capsaicin.mamane.lu>
Hi,

I was thinking about a sort of symmetric to rebase, a kind of "intelligent" mass cherry-pick. For the sake of example let's call it "basere", although a better name would have to be found.

While
 git rebase UPSTREAM
moves the *current* branch (and any commit in it, but not in UPSTREAM)
on top of UPSTREAM,
 git basere UPSTREAM
would "cherry-pick" all commits in UPSTREAM that are not in HEAD to
the current branch.

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. So maybe it should be an option to cherry-pick rather than a new command? E.g. --skip-same? What about making it cherry-picks *default* behaviour?

Why do I think it is useful? Take the case of a developer following two different origins A and B, and B uses rebase (not merge) to integrate changes from A, but not as often as one would like. A could for example be the "official" tree (e.g. linux Linus tree), and B a feature branch of a developer that is meant to eventually go into A "cleanly" at some future time and A's policy is that one has to rebase before sending a merge request. Then another developer wants to keep up with changes from *both* A and B. So, the situation could look like:

      A---A---A remotes/A/master
     /
X---X---B0---B1---L master
     \
      B0---B1---B2--B3 remotes/B/master
So one does "git rebase remotes/A/master master" and one gets
      A---A---A---B0---B1---L master
     /
X---X
     \
      B0---B1---B2--B3 remotes/B/master
I'd like to go to the situation:
      A---A---A---B0---B1---L---B2--B3 master
     /
X---X
     \
      B0---B1---B2--B3 remotes/B/master

Without having to manually find the cutoff point "B2" (or worse, if the history is more messy than that, as in:

      A---A---A---B1---L master
     /
X---X
     \
      B0---B1---B2--B3 remotes/B/master
)
The best way I have found to do that is:

git fetch B git checkout --no-track -b TMP remotes/B/master git rebase master git checkout master git merge --ff-only TMP git branch -d TMP

or less commands but more messy/fragile (and more work for git):

git fetch B git tag TMP git rebase remotes/B/master git rebase TMP git tag -d TMP

but that is rather onerous for something that should be just one command.

So what are your thoughts on that?
 - Good idea? Would you take a patch that does something like that?
 - Should it be cherry-picks's default behaviour?
 - An option to cherry-pick?
 - A new command? What name? Maybe "multi-cherry-pick"?
 - An option to rebase, e.g. "--pull" or "--incoming" or "--here"?
   ("--pull" is probably too confusing wrt to "git pull"; people will
    have trouble remembering which is which between "git pull
    --rebase" and "git rebase --pull"...)
-- 
Lionel
Next: Junio C Hamano
Message 1 of 4 in “Symmetric of rebase / more intelligent cherry-pick”
  1. Lionel Elie MamaneOct 11, 2011
  2. Junio C HamanoOct 11, 2011
  3. Junio C HamanoOct 11, 2011
  4. Jonathan NiederOct 11, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.