zlacker

[return to "Stacked Diffs with git rebase —onto"]
1. mytail+G8f[view] [source] 2025-12-05 14:32:19
>>flexdi+(OP)
Instead of "stacked diffs", isn't the more "continuous integration" solution to split a big feature into small chunks that actually get merged?

Having to rebase again and again is a symptom that a dev branch is living for too long.

◧◩
2. happyt+0lf[view] [source] 2025-12-05 15:26:44
>>mytail+G8f
This problem isn't specific to cases where you are rebasing "again and again". Just needing to do a single rebase (e.g. prior to opening a PR) for a stacked feature is enough to need a solution.

And, as others have pointed out, the modern solution is `--update-refs`, so there's no need for complicated workflows any more anyway.

If you mean rebasing as each PR in the stack is merged, most Git platforms have the ability to do that automatically.

◧◩◪
3. mytail+omf[view] [source] 2025-12-05 15:33:14
>>happyt+0lf
No, I mean small chunks that are actually merged instead of having a stack of them floating around.

A rebase before a merge can always happen, of course. But there are not stacked commits then it is just a standard rebase of your small chunk and that's it. And this will also have a shorter life than a stack so rebases will be rarer and simpler.

◧◩◪◨
4. happyt+opf[view] [source] 2025-12-05 15:45:30
>>mytail+omf
Oh, yes - but this is more about your situation than your style. Sometimes a feature is large and varied enough to beg multiple PRs, yet singular enough that you are not developing them serially (i.e. as you work on later parts, you are changing earlier parts). Most of the time this isn't the case.
[go to top]