> Human limitations. You are simply better able to digest small incremental changes, instead of one big blob. This is not controversial and i don't understand why you would even raise this as a point.
Because I agree with you on your assessment of human limitations, and rebase doesn’t change this. If I need to merge 500 lines of code over 20 affected files, and none of that can be merged individually while retaining functionality, it doesn’t matter if I split that into 50 10-line commits if I need to merge in the monolith at once, which means understanding the set of changes as a monolith, regardless of git history.
If for some reason any of this can be merged in as standalone, you just do that instead. This is what I mean by bikeshedding. Rebase culture is purely preference. There is nothing it offers that is not solved equally as well by potentially less complicated alternatives. It’s not the wrong way to do things, it’s just not also objectively right, and creates more work than it claims to solve.
> it doesn’t matter if I split that into 50 10-line commits if I need to merge in the monolith at once
That is a misunderstanding of how to use this feature. It is not meant to break changes
down into useless divisions. It is meant to allow the grouping of changes into logical
units. Logical units that help human comprehension.
This is very important when communicating with people who have never seen your code
before. It allows you to include a narrative description (commit message) with each
logical group of changes that is directly connected to the source code implementation
of just that descriptive piece. It also allows you to connect a chain of those logical units into a progression toward a greater, cohesive goal.
You may dismiss all this as irrelevant to your particular environment, and that is fine.
But Git provides tools that are directed toward it, and they're quite powerful and useful
for those who understand and use them correctly.
Because I agree with you on your assessment of human limitations, and rebase doesn’t change this. If I need to merge 500 lines of code over 20 affected files, and none of that can be merged individually while retaining functionality, it doesn’t matter if I split that into 50 10-line commits if I need to merge in the monolith at once, which means understanding the set of changes as a monolith, regardless of git history.
If for some reason any of this can be merged in as standalone, you just do that instead. This is what I mean by bikeshedding. Rebase culture is purely preference. There is nothing it offers that is not solved equally as well by potentially less complicated alternatives. It’s not the wrong way to do things, it’s just not also objectively right, and creates more work than it claims to solve.