3 ms·

I don't like this workflow, I see it as needlessly complicated. If you really can't cherry pick your big PR into simple branches to merge directly into master (

I don't like this workflow, I see it as needlessly complicated. If you really can't cherry pick your big PR into simple branches to merge directly into master (which I rarely have seen over the years), create a longer lived branch and make small PRs to that. Then merge longer lived branch into master. You should never be going off and work on huge changes without keeping in sync with the base branch. Stacked PRs make all this more difficult.

jedimastert 6y ago
I agree. I will regularly have a patch that lives for more than a month and I am rarely more than a couple days out of date. If the area you're working on is rarely touched, it isn't an issue. If you're constantly having merge conflicts, you might need to sync up with the team a bit more.
- smcameron 6y ago
  Horses for courses. These tools originated with linux kernel maintainers. I remember sending a patch to improve Andrew Morton's patch scripts, and he told me it was "slow". I was using a dumb algorithm for something, and so I asked him how many patches he had in his stack, and I don't remember the precise number, but I remember that it was in the thousands! My algorithm worked fine with 10 or 100 patches, but thousands? Hadn't occurred to me someone would be dealing with such a pile. I haven't had a pile that big myself, but I have had a pile that was in the low 100s.
- smcameron 6y ago
  The other use case that a stack of patches workflow really fits is for maintainers of open source linux drivers (what I used to do). In that case, you're maintaining the driver in the upstream kernel, but you also need to get your code into Redhat's various kernels, SuSE's, Ubuntu's, and whoever else is the flavor of the day. All those guys have several kernels they support and they're all a little bit different. Porting over a pile of small patches is really the only sane way to go for that job, and for that, these kind of tools are a godsend.
andrewstuart2 6y ago
Depends on the team you're on. "Small PRs" to some people could mean a few lines. But if those few lines are required for the next thing I do, on the same day, and I don't want to mess around with refactors or merge conflicts if somebody merges out of order, and I'm not going to get enough eyes on the PR quickly enough, this is exactly the strategy I've used before, minus the tools. Just stack up some very very small MRs in the order they're depending and you can easily have people understand the changes across them without wasting time solving merge conflicts you already knew you'd otherwise have to deal with.
- aledalgrande 6y ago
  In that case I just use git stash. Stay on the branch you need and keep working, stash when needing to make changes to the open PR.
house9-2 6y ago
> create a longer lived branch and make small PRs to that. I follow this pattern a lot, we call it an epic branch and usually name it something like `epic/foobar`
- kqr 6y ago
  Yeah, that works as long as only one person does this, and they regularly merge into and out of master. Otherwise you still get all the communication and feedback problems long lived branches have.
tta 6y ago
I have a couple of comments here. > You should never be going off and work on huge changes without keeping in sync with the base branch. I agree, but the stacked PR approach doesn't preclude this. If you periodically `autorebase` the stack against `origin/master` right after a `git fetch origin`, your stack stays in sync with `master`. > ate a longer lived branch and make small PRs to that. Then merge longer lived branch into master Large features don't necessarily imply long-running feature branches, though. I personally prefer feature flags (or some other mechanism for conditional execution) on the base branch for features that are "open" for more than a week or so, say. "Large" is also subjective. You could have changes that are large in terms of lines of code added, the number of services that are being touched, or the number of different+unrelated concerns involved. As an example, this week I worked on a semi-greenfield Kafka service. Stacking PRs helped me keep track of the review process a lot more easily than "one big PR" would allow, and the stack was merged in 4-ish days. I structured the stack like this: - Add a `proto` file covering messages that this Kafka consumer reads off the incoming topic - Pull in a gradle library for protobuf code generation - Add in a simple Kafka consumer and producer - Add a `Processor` that works on incoming messages - Hook everything up; the sevice consumes off Kafka, "processes" the data, and produces back to Kafka These PRs aren't similar in terms of size or complexity, but the various concerns that comprise this service are nicely split up. > Stacked PRs make all this more difficult. I'm in agreement. Stacked PRs involve more overhead, but there are times when this is a reasonable tradeoff.

jedimastert 6y ago

I agree. I will regularly have a patch that lives for more than a month and I am rarely more than a couple days out of date. If the area you're working on is rarely touched, it isn't an issue. If you're constantly having merge conflicts, you might need to sync up with the team a bit more.

smcameron 6y ago
Horses for courses. These tools originated with linux kernel maintainers. I remember sending a patch to improve Andrew Morton's patch scripts, and he told me it was "slow". I was using a dumb algorithm for something, and so I asked him how many patches he had in his stack, and I don't remember the precise number, but I remember that it was in the thousands! My algorithm worked fine with 10 or 100 patches, but thousands? Hadn't occurred to me someone would be dealing with such a pile. I haven't had a pile that big myself, but I have had a pile that was in the low 100s.
smcameron 6y ago
The other use case that a stack of patches workflow really fits is for maintainers of open source linux drivers (what I used to do). In that case, you're maintaining the driver in the upstream kernel, but you also need to get your code into Redhat's various kernels, SuSE's, Ubuntu's, and whoever else is the flavor of the day. All those guys have several kernels they support and they're all a little bit different. Porting over a pile of small patches is really the only sane way to go for that job, and for that, these kind of tools are a godsend.

andrewstuart2 6y ago

Depends on the team you're on. "Small PRs" to some people could mean a few lines. But if those few lines are required for the next thing I do, on the same day, and I don't want to mess around with refactors or merge conflicts if somebody merges out of order, and I'm not going to get enough eyes on the PR quickly enough, this is exactly the strategy I've used before, minus the tools. Just stack up some very very small MRs in the order they're depending and you can easily have people understand the changes across them without wasting time solving merge conflicts you already knew you'd otherwise have to deal with.

aledalgrande 6y ago
In that case I just use git stash. Stay on the branch you need and keep working, stash when needing to make changes to the open PR.

house9-2 6y ago

> create a longer lived branch and make small PRs to that. I follow this pattern a lot, we call it an epic branch and usually name it something like `epic/foobar`

kqr 6y ago
Yeah, that works as long as only one person does this, and they regularly merge into and out of master. Otherwise you still get all the communication and feedback problems long lived branches have.

tta 6y ago

I have a couple of comments here. > You should never be going off and work on huge changes without keeping in sync with the base branch. I agree, but the stacked PR approach doesn't preclude this. If you periodically `autorebase` the stack against `origin/master` right after a `git fetch origin`, your stack stays in sync with `master`. > ate a longer lived branch and make small PRs to that. Then merge longer lived branch into master Large features don't necessarily imply long-running feature branches, though. I personally prefer feature flags (or some other mechanism for conditional execution) on the base branch for features that are "open" for more than a week or so, say. "Large" is also subjective. You could have changes that are large in terms of lines of code added, the number of services that are being touched, or the number of different+unrelated concerns involved. As an example, this week I worked on a semi-greenfield Kafka service. Stacking PRs helped me keep track of the review process a lot more easily than "one big PR" would allow, and the stack was merged in 4-ish days. I structured the stack like this: - Add a `proto` file covering messages that this Kafka consumer reads off the incoming topic - Pull in a gradle library for protobuf code generation - Add in a simple Kafka consumer and producer - Add a `Processor` that works on incoming messages - Hook everything up; the sevice consumes off Kafka, "processes" the data, and produces back to Kafka These PRs aren't similar in terms of size or complexity, but the various concerns that comprise this service are nicely split up. > Stacked PRs make all this more difficult. I'm in agreement. Stacked PRs involve more overhead, but there are times when this is a reasonable tradeoff.