4 ms·

Git gets its bias from the Linux kernel development. When you're sharing your source changes with external people, who need to review your code, it just makes

by tux1968 3y ago

Git gets its bias from the Linux kernel development. When you're sharing your source changes with external people, who need to review your code, it just makes sense to present it in a clean, logical progression of changes. To wit, remove unnecessary noise like your development missteps. And it's only in that context that the emphatic call for history rewriting is born. Meaning, you can use all the power of Git to record all your changes as you proceed through development, and then rebase them into something presentable for the greater world.

Groxx 3y ago
It's also useful in code reviews in general - I don't care about your development noise, and every single person in the future does not need to read it to understand the final result either. Rebases solve that: present a coherent story for easy understanding, rather than the messy reality. When you're purely local, sure - do whatever the heck you want. Nobody cares. But messy merges are rough for collaboration, both present and future. (rough, not fundamentally wrong, to be clear. It's just a friction tradeoff, dealing with human behavior has next to no absolutes)
- WirelessGigabit 3y ago
  My largest problem about rebasing a branch onto master as a single commit is that it becomes harder to do provenance. When the tip of my branch gets built (1) and the merge target is not ahead (2) I can actually retag the output of the build of the branch as what is now on master. When you do a squash, while the default commit message contains the SHA, it no longer carries a semantical meaning. It's just a string of text.
appplication 3y ago
It feels like overindexing on git as a source of truth for the iterative development process itself is just bikeshedding. Do whatever you want to do locally, then squash your commits into a single unit change. Document that comprehensively in your commit message for that squashed change. If there was some profound learning that feels like it needs rebase history for, just explain it narratively. Perhaps a more contentious take: rebasing doesn’t bring any real value. To the original comment above, I would say a significant percentage of teams never use rebase and drive business value just fine. I do not think there exists and evidence to suggest teams that use rebase over squash merging are in some way higher performing. Rebase is something that some people’s obsessiveness compels them to care abut because they can, and then retroactively justify their decisions by suggesting value that isn’t there.
- tux1968 3y ago
  > squash your commits into a single unit change. 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.
  - appplication 3y ago
    > 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.
    - tux1968 3y ago
      > 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.
      - appplication 3y ago

Groxx 3y ago

It's also useful in code reviews in general - I don't care about your development noise, and every single person in the future does not need to read it to understand the final result either. Rebases solve that: present a coherent story for easy understanding, rather than the messy reality. When you're purely local, sure - do whatever the heck you want. Nobody cares. But messy merges are rough for collaboration, both present and future. (rough, not fundamentally wrong, to be clear. It's just a friction tradeoff, dealing with human behavior has next to no absolutes)

WirelessGigabit 3y ago
My largest problem about rebasing a branch onto master as a single commit is that it becomes harder to do provenance. When the tip of my branch gets built (1) and the merge target is not ahead (2) I can actually retag the output of the build of the branch as what is now on master. When you do a squash, while the default commit message contains the SHA, it no longer carries a semantical meaning. It's just a string of text.

appplication 3y ago

It feels like overindexing on git as a source of truth for the iterative development process itself is just bikeshedding. Do whatever you want to do locally, then squash your commits into a single unit change. Document that comprehensively in your commit message for that squashed change. If there was some profound learning that feels like it needs rebase history for, just explain it narratively. Perhaps a more contentious take: rebasing doesn’t bring any real value. To the original comment above, I would say a significant percentage of teams never use rebase and drive business value just fine. I do not think there exists and evidence to suggest teams that use rebase over squash merging are in some way higher performing. Rebase is something that some people’s obsessiveness compels them to care abut because they can, and then retroactively justify their decisions by suggesting value that isn’t there.

tux1968 3y ago
> squash your commits into a single unit change. 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.
- appplication 3y ago
  > 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.
  - tux1968 3y ago
    > 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.
    - appplication 3y ago