Hacker News Reader

Comment by RHSeeger | Hacker News Reader

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

View on HN

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

(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 :)

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.

How do you deal with rebases when you have to?

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.

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 :)

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.

I have an extra script in the CI job to detect rebased/squashed commits and fail the build if they're present.

Reply on news.ycombinator.com