Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others.
This is clearly not relevant to everyone, but to suggest there is no value at all, is laughable.
> You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline.
If we take away “this is how it’s historically done” or “because I know how these maintainers act and they would not accept it” - why not? From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable?
> allows piecemeal selection of acceptable bits, and rejection of others
Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasing.
> From what principles is the Linux kernel special that standalone incremental units of change are inappropriate or undesirable?
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.
> Sure, is a good thing, but doesn’t have much to do with git and can be done without rebasing.
It does have something to do with Git. Git has tools to facilitate it. And that is the case because Git was born out of Linux kernel development where it was the norm, and necessary.
If you want to use another tool to achieve the same result, nobody is stopping you. Or if you don't want to do it at all, that's fine too. But the simple fact of the matter is, you must do it today if you want to participate in kernel development.
> 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.
> to suggest there is no value at all, is laughable.
It can have no value at all to common workflows. Usually, this kind of singular change consideration is done at the PR level in another tool (github), which is divorced from git. Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged.
> Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged
Fortunately, you're able to include anything you think is relevant. If you think a change is worthy of inclusion, include it. But there are clearly things that are just silly mistakes that provide no such value, and cleaning those up as a courtesy for the person who has to review your code, just makes sense.
> But there are clearly things that are just silly mistakes that provide no such value, and cleaning those up as a courtesy for the person who has to review your code, just makes sense.
Maybe nobody cares about your missteps, true. What about less senior developers? Is there a learning opportunity both ways? Yes. The history pepper doesn't matter either way. There's a little value to think about that in the workflow I described, so we don't toss it (not that anyone can make you expose it).
Having a clean history, where every commit is capable of being compiled, is quite nice. This will keep your CI happy and allow you to more easily use git bisect to determine when a bug was introduced to the codebase.
> There's a little value to think about that in the workflow I described
Sure. Git is flexible and doesn't require you to follow the workflow for which it was originally designed.
Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others.
This is clearly not relevant to everyone, but to suggest there is no value at all, is laughable.