5 ms·

One thing I wish git did (maybe it does and I don't know how?) is to be able to say that a new branch is based off an old branch (not a commit that used to be t

One thing I wish git did (maybe it does and I don't know how?) is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). so I can branch a single pr in progress to start the next. Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch. Currently, one can just do it by never modifying the underlying "branch" (i.e. just adding new commits), but in practice that doesn't always work, as many times you have to rebase against one's master/main branch to pull in changes, which even if no conflicts, will reflow your "base" branch" changing all the commits. 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. possible? stupid idea? thoughts?

bqmjjx0kac 4y ago
It sounds like you're describing what `git branch --set-upstream-to=$otherBranch` does?
regularjack 4y ago
Isn't that how rebase already works? It will "apply" commits of the current branch onto commits of the base branch, including new commits that were created in the meantime.
theptip 4y ago
This is one of the big features from git-branchless (https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-...) which is recommended in the article; moving a stack (sub-tree) of commits instead of just one branch. Might be useful for you if you find the rebase flow to be painful. In particular this can be good for local prototyping where you have a bunch of functional candidates on top of some foundational refactors, and you may be rebasing frequently to refine those foundational commits.
- arxanas 4y ago
  Also worth pointing out these commands from git-branchless (I'm the author): - git sync: rebase all commit stacks on top of the main branch. - git restack: run after making a change to a foundational commit to automatically restack dependent commits.
dan-robertson 4y ago
It feels like roughly the issue is that git thinks in terms of snapshots whereas people often think in terms of patches. Darcs and pijul are version control systems that try to have patches as the fundamental object you operate on instead of snapshots. In particular, there isn’t a rerere operation to change the base of a commit because patches don’t have bases in the same way. However if you’re reviewing code you probably do care about the base because changing the base may change the meaning of the branch and if eg some library function is renamed between when you write/approve a patch and when you merge it, the patch may no-longer be valid.
8K832d7tNmiQ 4y ago
> I wish git did is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). > Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch. You'd still end up fixing all the conflicts your branch made either way, and also breaking the flow of commits if you didn't update the message. So why bother doing all of that instead of stashing your current project, rebase, and force push it? I believe that's supposed to be the standard approach to handle conflict changes in PRs.
msbarnett 4y ago
> 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?
- compsciphd 4y ago
  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?
epage 4y ago
git-stack [0] tries to do that. I also maintain a list of related tools, some of which do similar [1]. [0] https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack [1] https://github.com/gitext-rs/git-stack/blob/main/docs/comparison.md https://github.com/gitext-rs/git-stack/blob/main/docs/compar...
zackmorris 4y ago
Came here to say the same thing. I always rebase my own branch onto the trunk and force-push before merging. But that's hard to explain to other developers, and there's no way to enforce it, so the repo inevitably becomes filled with overlapping merges, which is an unforced error IMHO. Does anyone know if there's a way to only allow rebase-and-merge on GitHub and GitLab? https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#rebase-and-merge-your-pull-request-commits https://docs.github.com/en/pull-requests/collaborating-with-... https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase-from-the-gitlab-ui https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase...
- morelisp 4y ago
  In GitLab this is referred to as "Merge commit with semi-linear history" and it's a checkbox in the general MR settings.
ecnahc515 4y ago
With `git rebase --onto <new_base> <previous_base>` you can achieve this, but it isn't as easy as it could be.

bqmjjx0kac 4y ago

It sounds like you're describing what `git branch --set-upstream-to=$otherBranch` does?

regularjack 4y ago

Isn't that how rebase already works? It will "apply" commits of the current branch onto commits of the base branch, including new commits that were created in the meantime.

theptip 4y ago

This is one of the big features from git-branchless (https://github.com/arxanas/git-branchless/wiki/Command:-git-move https://github.com/arxanas/git-branchless/wiki/Command:-git-...) which is recommended in the article; moving a stack (sub-tree) of commits instead of just one branch. Might be useful for you if you find the rebase flow to be painful. In particular this can be good for local prototyping where you have a bunch of functional candidates on top of some foundational refactors, and you may be rebasing frequently to refine those foundational commits.

arxanas 4y ago
Also worth pointing out these commands from git-branchless (I'm the author): - git sync: rebase all commit stacks on top of the main branch. - git restack: run after making a change to a foundational commit to automatically restack dependent commits.

dan-robertson 4y ago

It feels like roughly the issue is that git thinks in terms of snapshots whereas people often think in terms of patches. Darcs and pijul are version control systems that try to have patches as the fundamental object you operate on instead of snapshots. In particular, there isn’t a rerere operation to change the base of a commit because patches don’t have bases in the same way. However if you’re reviewing code you probably do care about the base because changing the base may change the meaning of the branch and if eg some library function is renamed between when you write/approve a patch and when you merge it, the patch may no-longer be valid.

8K832d7tNmiQ 4y ago

> I wish git did is to be able to say that a new branch is based off an old branch (not a commit that used to be that branches head). > Then if I change the base pr in progress (say via rebase or via squashing or the like), I can easily rebase my new commits in the new pr on top of the current state of the branch. You'd still end up fixing all the conflicts your branch made either way, and also breaking the flow of commits if you didn't update the message. So why bother doing all of that instead of stashing your current project, rebase, and force push it? I believe that's supposed to be the standard approach to handle conflict changes in PRs.

msbarnett 4y ago

> 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?

compsciphd 4y ago
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?

epage 4y ago

git-stack [0] tries to do that. I also maintain a list of related tools, some of which do similar [1]. [0] https://github.com/gitext-rs/git-stack https://github.com/gitext-rs/git-stack [1] https://github.com/gitext-rs/git-stack/blob/main/docs/comparison.md https://github.com/gitext-rs/git-stack/blob/main/docs/compar...

zackmorris 4y ago

Came here to say the same thing. I always rebase my own branch onto the trunk and force-push before merging. But that's hard to explain to other developers, and there's no way to enforce it, so the repo inevitably becomes filled with overlapping merges, which is an unforced error IMHO. Does anyone know if there's a way to only allow rebase-and-merge on GitHub and GitLab? https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#rebase-and-merge-your-pull-request-commits https://docs.github.com/en/pull-requests/collaborating-with-... https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase-from-the-gitlab-ui https://docs.gitlab.com/ee/topics/git/git_rebase.html#rebase...

morelisp 4y ago
In GitLab this is referred to as "Merge commit with semi-linear history" and it's a checkbox in the general MR settings.

ecnahc515 4y ago

With `git rebase --onto <new_base> <previous_base>` you can achieve this, but it isn't as easy as it could be.