Comment by msbarnett | Hacker News Reader

Comment by msbarnett | Hacker News Reader

Parent Full thread

> TLDR: Basically, want to be able to state that branch depends on branch (which is currently commit id x) but if I rebase, use whatever the current commit id is for that branch, not whatever it was when I first made the branch.

As far as I can tell (the “problem” you’re describing is a bit vague) this is already how git works with the sole exception being that git doesn’t default to a particular branch for a rebase?

eg) all you seem to de describing here is a bog-standard:

     (on feature-branch1)> git checkout -b feature-branch2

<do some work on feature-branch2, return to feature-branch1 and make some more changes there, now you want to catch feature-branch2 up with feature-branch1>

     (on feature-branch2)> git rebase feature-branch1

<now we’re branched off of the new tip of feature-branch1, not where we originally branched>

All it seems like you’re asking for us to drop “feature-branch1” from the rebase?

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?

Reply on news.ycombinator.com