4 ms·

> The blocker here isn’t Git. In fact, the reason you can’t go with option #4 is that your code review tools probably don’t support it I do stacked commits (br

> The blocker here isn’t Git. In fact, the reason you can’t go with option #4 is that your code review tools probably don’t support it I do stacked commits (branches off branches) all the time. Github certainly supports PRs based on such.

jas14 5y ago
I still haven't found a reliable way to prevent merging branches that aren't the first in the stack :/
- fosterfriends 5y ago
  (Graphite engineer) We had the same problem. Coded in a feature that prevents you from casually merging branches that are not bottom of the stack :)
- _freds 5y ago
  What I usually do is if I need to stack more PRs I open them as a draft to avoid accidental merges. I then convert each PR to a non-draft as I “pop” the stack.
tomasreimers 5y ago
How do you deal with rebases when you have to?
- sigil 5y ago
  Like so: git switch offshoot git rebase --onto feature branchpoint^ Will replay your offshoot branch onto its underlying feature branch after the feature branch has been rebased. The branchpoint is the first commit that diverges from the feature branch. Finding the branchpoint commit is the only real annoyance here -- if there's a ref or a better trick for finding it, I'm all ears.
  - connorbrinton 5y ago
    My usual workflow to rebase a stacked set of feature branches off of main is: git checkout main git pull git checkout feature-branch-1 git rebase -i - git checkout feature-branch-2 git rebase -i - ... There's most likely a more efficient way to do this, but I find that referring to the most recently checked-out branch with a single hyphen is a lesser-known feature, so perhaps it will be helpful :)
    - sigil 5y ago
      Nice, didn't know about `-`. What's your process once you're in the interactive rebase? The `git rebase --onto` I use is noninteractive and could be an alias, were it not for the business of finding the `branchpoint` commit.
- lmm 5y ago
  I have an extra script in the CI job to detect rebased/squashed commits and fail the build if they're present.

jas14 5y ago

I still haven't found a reliable way to prevent merging branches that aren't the first in the stack :/

fosterfriends 5y ago
(Graphite engineer) We had the same problem. Coded in a feature that prevents you from casually merging branches that are not bottom of the stack :)
_freds 5y ago
What I usually do is if I need to stack more PRs I open them as a draft to avoid accidental merges. I then convert each PR to a non-draft as I “pop” the stack.

tomasreimers 5y ago

How do you deal with rebases when you have to?

sigil 5y ago
Like so: git switch offshoot git rebase --onto feature branchpoint^ Will replay your offshoot branch onto its underlying feature branch after the feature branch has been rebased. The branchpoint is the first commit that diverges from the feature branch. Finding the branchpoint commit is the only real annoyance here -- if there's a ref or a better trick for finding it, I'm all ears.
- connorbrinton 5y ago
  My usual workflow to rebase a stacked set of feature branches off of main is: git checkout main git pull git checkout feature-branch-1 git rebase -i - git checkout feature-branch-2 git rebase -i - ... There's most likely a more efficient way to do this, but I find that referring to the most recently checked-out branch with a single hyphen is a lesser-known feature, so perhaps it will be helpful :)
  - sigil 5y ago
    Nice, didn't know about `-`. What's your process once you're in the interactive rebase? The `git rebase --onto` I use is noninteractive and could be an alias, were it not for the business of finding the `branchpoint` commit.
lmm 5y ago
I have an extra script in the CI job to detect rebased/squashed commits and fail the build if they're present.