think of it this way. When I say git branch ..., I'm creating a new branch pointer that points to a commit and any future commit will update that branch point

think of it this way. When I say git branch ..., I'm creating a new branch pointer that points to a commit and any future commit will update that branch pointer (not the original). if I then add a new commit to the original branch, I'll update its branch pointer. if I do then do a git rebase -i original_branch (on new branch), (I believe) git will look for the common ancestor commit, update the head to original_branch's current id, and then apply individual every commit id from that common ancestor to the head of my what was my new branch. if I just add a commit to original branch, this is "clean" (i.e. i might have lots of conflicts, but it makes sense, its just effectively inserting a new commit into the middle of the commit stream). However, if I have rebased the original branch, such that common ancestor isn't where it used to be, but much further back in time), it no longer makes sense. What I was proposing (and what I could do manually), is when i rebase against the proposed type of branch, then we essentially, move the head to the current head of the updated "old branch" and then cherry-pick one by one each commit i made against the new branch (fixing merge errors along the way, just like with rebase). is this a bit clearer?