git rebase分支与祖父母

Question

I am reading about git rebase and was reading through - git-scm 's documentation.

I have a specific doubt about using the onto feature of git rebase to rebase a branch to its grandparent (just like the case in above link).
Let us assume we have a branch/commit structure like the following:

C1 <- C2 <- C5 <- C6 [master]
         <- C3 <- C4 <- C10 [server]
               <- C8 <- C9 [client]

Now, I want to rebase client brnach onto master . I checked out client branch and ran git rebase --onto master server client command. The resultant structure I got (after merging and fast-forwarding master to client) from this command is:

C1 <- C2 <- C5 <- C6 <- C8' <- C9' [master, client]
         <- C3 <- C4 <- C10 [server]

My doubt is, what if my changes in client branch were depending on C3 commit in server branch. The resultant code in master branch would certainly fail in such a scenario as rebase does . As far as my knowledge goes, shouldn't the actual result (after merging and fast-forwarding master to client) be like:

 C1 <- C2 <- C5 <- C6 <- C3' <- C8' <- C9' [master, client]
                             <- C4 <- C10 [server]

Can somebody please let me know whether my understanding/concern is wrong?

Answer 1

If you start from

C1---C2---C5---C6  master
       \
        C3---C4---C10  server
          \
           C8---C9  client

and you expect the result to be

C1---C2---C5---C6---C3'---C8'---C9' master, client
                      \
                       C4---C10  server

Then the misunderstanding is: C3' cannot be the ancestor of C4 . That cannot happen here.

When you do

git rebase --onto master server client

and, as you put it, changes in client "depend" on changes from C3 , you can resolve the merge and you'll get

C1---C2---C5---C6  master
       \         \
        \         C8'---C9' client
         \
          C3---C4---C10  server

Now, after you merge master and client , and you are ready to rebase server , two scenarios could happen:

1. If you kept the changes from C8 that "depend" on C3 in the previous conflict, after you resolve the current conflict git will say

No changes - did you forget to use 'git add'? If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch .

When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort".

You can then do

git rebase --skip

and you'll get

C1---C2---C5---C6---C8'---C9'  master, client  
                             \         
                              C4'---C10' server

Notice there is no C3' as those changes were applied with C8' .

2. If you did not keep the changes from C8 that "depend" on C3 in the previous conflict, after you resolve the current conflict and do

git rebase --continue

you'll get

C1---C2---C5---C6---C8'---C9'  master, client
                             \         
                              C3'---C4'---C10' server

Which means that when there are changes on <branch> "depending" on <upstream> that conflict with <newbase> when rebasing, git provides you the merge resolution mechanism as a way to choose if you want those changes now or later.

Answer 2

My doubt is, what if my changes in client branch were depending on C3 commit in server branch. The resultant code in master branch would certainly fail in such a scenario as rebase does

That's right. You've explicitly sliced commit C3 out of your rebased history. Why do that? Just git rebase master client . When you merge server git won't try to apply the C3 changes again because they won't show up in the diffs (or alternately further changes to those lines will conflict).

edit: comoits aren't "on" branches. The history matters. The branch names are just lightweight ("throwaway" wouldn't be such a bad word here) references to help identify the commits that interest you. Focus on the commtts themselves and their ancestry.