CODEWITHSUNDEEP
git
Andy K
Andy K

Reputation: 5054

How to write the commits of a remote branch to my local branch?

I have a remote branch, let's called it FIN-985_the_original. I have my local branch, which is called FIN-985_v2. FIN-985_v2 is a branch from master.

I did two commands and I'm confused as one clearly gave me what I want

First one is the one below

git rebase --onto FIN-985_the_original FIN-985_v2

This one put the content of FIN-985_the_original into FIN-985_v2, issue is it seems to replace the contents of FIN-985_the original into FIN-985_v2, wiping out the commits done into FIN-985_v2.

The second part seems to give me what I want but it kind of defy my logic

git checkout FIN-985_the_original
git rebase FIN-985_v2

I was expecting that the the rebase would be done on FIN-985_v2 and instead, it was done on FIN-985_the_original. From my command, I know it makes sense as the checkout was done on FIN-985_the_original but it bugs my logic as I've read this

Any tips are more than welcomed to deconfuse me.

Cheers

Upvotes: 0

Views: 44

Answers (1)

joanis
joanis

Reputation: 12260

Basic rebase (your second case)

I'll start with your second case, since that's the easier one to explain.

git checkout A
git rebase B

asks Git to take any commits in A that are not in B, and move them to the end of B.

Sample scenario:

-- 0 (master)
    \
     1 -- 2 -- 3 (B)
      \
       4 -- 5 (A)

If, while A is checked out, I do git rebase B, I pluck commits 4 and 5 (they're on A but not on B) and move them to the end of B:

-- 0 (master)
    \
     1 -- 2 -- 3 (B)
                \
                 4' -- 5' (A)

So now A will have all the commits of B followed by the commits of A.

In your case, the commits of the_original should now be after those of v2, and the_original should be a branch of v2, although I'm not sure that's what you're saying happened.

Using --onto

When you use --onto, things get weird. I'll start with a checkout again because the branch that is currently checked out still is the one being moved:

git checkout A
git rebase --onto C B

asks Git to take the commits that are on A but not on B and move them, same as without --onto. But now, we gave the rebase a destination: put them at the end of C.

Let's add C to my initial scenario:

     6 (C)
    /
-- 0 (master)
    \
     1 -- 2 -- 3 (B)
      \
       4 -- 5 (A)

Since I'm on A, we're still going to move 4 and 5: they're on A but not on B; but we'll place them on C, i.e., after 6:

       6 (C)
      / \
     /   4' -- 5' (A)
    /
-- 0 (master)
    \
     1 -- 2 -- 3 (B)

So in your case, what should have happened depends on what was checked out before the rebase: the commits in the branch that was checked out that were not in v2 should have gotten moved to the end of the_original.

I find I rarely want --onto, and frankly I find it confusing enough that I would probably cherry pick the commits around instead of using git rebase --onto...

Pedantic notes

Following the convention at https://git-scm.com/docs/git-rebase, I'm using ' to mark the moved commits, since 4' and 5' are new commits reproducing 4 and 5, not 4 and 5 themselves.

I'm taking a linguistic shortcut when I say "moved": commits are not technically moved, they are re-applied, thus creating new commits that look more or less the same as the originals.

Upvotes: 2

Related Questions