4 ms·

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 rebas

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.

glenjamin 11mo ago
I’m amazed that this comment is so low down Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP Absolutely everything gets easier when you lower your work in progress.
- happytoexplain 11mo ago
  This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.
  - glenjamin 11mo ago
    I invite you to look into feature flagging. It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time. That's exactly how I've worked for the past decade or so.
    - thunderfork 11mo ago
      [dead]
  - SideburnsOfDoom 11mo ago
    > It's very normal to be working on a feature that depends on a not-yet-merged feature. Oh sure, many bad ideas and poor practises such as that one are quite "normal". It's not a recommendation.
happytoexplain 11mo ago
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.
- mytailorisrich 11mo ago
  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.
  - happytoexplain 11mo ago
    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.
    - mytailorisrich 11mo ago
      My experience is that you should always aim for frequent small commits. This is what continuous integration and trunk-based development advocate and it saves a lot of headaches and the need to come up with "exotic" solutions to problems created by big, long-lived dev branches. This is quite orthogonal to developing parts serially or not, and it is perfectly fine to change or refactor ealier parts when you work on later parts. Development is an iterative process. It seems to me that "stacked diffs" are an example of looking for a technical solution to process issue.

glenjamin 11mo ago

I’m amazed that this comment is so low down Stacked diffs seems like a solution to managing high WIP - but the best solution to high WIP is always to lower WIP Absolutely everything gets easier when you lower your work in progress.

happytoexplain 11mo ago
This seems idealistic. It's very normal to be working on a feature that depends on a not-yet-merged feature.
- glenjamin 11mo ago
  I invite you to look into feature flagging. It is entirely viable to never have more than 1 or 2 open pull requests on any particular code repository, and to use continuous delivery practices to keep deploying small changes to production 1 at a time. That's exactly how I've worked for the past decade or so.
  - thunderfork 11mo ago
    [dead]
- SideburnsOfDoom 11mo ago
  > It's very normal to be working on a feature that depends on a not-yet-merged feature. Oh sure, many bad ideas and poor practises such as that one are quite "normal". It's not a recommendation.

happytoexplain 11mo ago

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.

mytailorisrich 11mo ago
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.
- happytoexplain 11mo ago
  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.
  - mytailorisrich 11mo ago
    My experience is that you should always aim for frequent small commits. This is what continuous integration and trunk-based development advocate and it saves a lot of headaches and the need to come up with "exotic" solutions to problems created by big, long-lived dev branches. This is quite orthogonal to developing parts serially or not, and it is perfectly fine to change or refactor ealier parts when you work on later parts. Development is an iterative process. It seems to me that "stacked diffs" are an example of looking for a technical solution to process issue.