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

Re: Help understanding "rebase"

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 11, 2009, 09:24 UTC
Message-ID
<49B7835F.4020503@drmicha.warpmail.net>
In-Reply-To
<KVXTFwpJn-0uEQYfgfg9YwrrimNYx6hbxe73y6qLYxfHYZH9eE4N4g@cipher.nrlssc.navy.mil>
Brandon Casey venit, vidit, dixit 10.03.2009 22:30:
Show 45 quoted lines
> John M. Dlugosz wrote:
>> Here is the situation:  An old topic branch containing 3 commits.  A dev
>> branch that has recently been merged.  To catch up the topic's work
>> before adding it to dev, I expected that rebase would do what I ended up
>> doing manually, detailed below.
>>
>> Instead, it crunched away for a long time and gave errors applying patches.
>>
>> So I did it manually by checking out dev, then cherry-picking each of
>> the three commits. Actually, this left it on top of dev, but suppose I
>> had created a new branch at dev, cherry-picked the stuff from the old
>> topic branch, and then deleted the old topic branch.  Now I have a new
>> topic branch with the rebased changes, albeit with a different branch
>> name.  Point is, there were no conflicts and the changes were simple, so
>> cherry-picking each node was clean.
>>
>> So, what did the rebase command try to do?  I think it may have
>> something to do with finding a common root between the topic and dev,
>> which, due to the merge, was a long way back.  Something like this:
>>
>>       o--o--   ...  --o
>>      /                 \
>>     A--...--B--   ... --C--D <== dev
>>              \
>>                   q--r--s  <== topic
>>
>>
>> I was able to cherry-pick q,r,s on top of D without any issues.  So why
>> did rebase get in such a tizzy?
> It may help those who know the internals of git-rebase if you supplied the
> commands you used and your git version.
> 
> So, you're saying you did
> 
>    git checkout topic
>    git rebase dev
> 
> or the equivalent
> 
>    git rebase dev topic
> 
> ?  Are you sure you didn't get the arguments to rebase reversed?
> 
> -brandon
> 

That happens very easily: You want to rewrite dev using rebase, so you check out dev. You want to rebase the topic branch, so you run "git rebase topic". Very logical, but the wrong way round... The doc is clear, though.

A useful mnemonic is that git rebase A B is about the commits A..B (B defaulting to the current branch), and that the new B after rebasing will be

B' = C + (A..B)

where C is the value of --onto, which defaults to A. The point of rebase is that A + (A..B) does not equal B in general, even though A..B=^A B ;)

git rebase A does not rewrite/rebase A! I'll think about a concise first paragraph for git-rebase.txt.

Michael
Previous: Brandon Casey
Message 3 of 3 in “Help understanding "rebase"”
  1. John M. DlugoszMar 10, 2009
  2. Brandon CaseyMar 10, 2009
  3. Michael J GruberMar 11, 2009

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.