3 ms·

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, th

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
      > 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.
      - tux1968 3y ago
        > 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.
- Supermancho 3y ago
  > 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.
  - tux1968 3y ago
    > 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.
    - Supermancho 3y ago
      > 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).
      - tux1968 3y ago
        > The history pepper doesn't matter either way. 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.
rewmie 3y ago
> Perhaps a more contentious take: rebasing doesn’t bring any real value. I strongly disagree. I rebase feature branches on a daily basis and it's a must-have feature for anyone who works on feature branches that you want to keep updated and mergeable as fast-forward merges and ideally peel off small commits in separate pull requests. Here's a small example of a very mundane workflow. I was assigned an issue where I needed to enable a component in a legacy project. I cut the feature branch and started going the "lean on the compiler" approach to fix blockers. Each individual blocker I addressed I saved as a local commit. Throughout the process I spotted a couple of bugs in mainline, which I also saved as local commits. Finally I got a working local build, but team members already merged a few updates onto mainline that created conflicts. I rebased my feature branch onto mainline's HEAD and fixed the conflicts in each local commit. Time to post pull requests for the fixes. I noticed a few of them were related so it would be preferable they went in before everything else. I did an interactive rebase to reorder local commits to move these bugfix commits to the start of the local branch. I squashed them, cleaned them up, and posted a pull request. The pull request was merged into mainline and in the meantime other PRs went in as well. I rebase the remaining commits in the local branch. Followed the same process for another bug. Rinse and repeat. Finally all I had left was the fix for the original issue. I rebased the remaining commits onto mainline, cleaned them up, and posted a PR. Done. One ticket, around 3 PRs, and almost a 1:1 ratio of rebase-to-PR. And here you are, saying rebasing doesn't bring any real value. I think those who complain about rebase are overrepresented by the subset of Git users who barely go beyond the very basic features of checking out branches, pulling changes, and committing stuff. They have no idea how and why other features work, so they complain about things they know nothing about. When pressed about basic usecases, they fall back to trying to fill in the holes in their reasoning by arguing that workflows should be different or that other features are similar, while completely ignoring that features like rebase do the job and do the job very well and very easily.
- deleted 3y ago
  [deleted]

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
    > 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.
    - tux1968 3y ago
      > 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.
Supermancho 3y ago
> 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.
- tux1968 3y ago
  > 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.
  - Supermancho 3y ago
    > 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).
    - tux1968 3y ago
      > The history pepper doesn't matter either way. 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.

rewmie 3y ago

> Perhaps a more contentious take: rebasing doesn’t bring any real value. I strongly disagree. I rebase feature branches on a daily basis and it's a must-have feature for anyone who works on feature branches that you want to keep updated and mergeable as fast-forward merges and ideally peel off small commits in separate pull requests. Here's a small example of a very mundane workflow. I was assigned an issue where I needed to enable a component in a legacy project. I cut the feature branch and started going the "lean on the compiler" approach to fix blockers. Each individual blocker I addressed I saved as a local commit. Throughout the process I spotted a couple of bugs in mainline, which I also saved as local commits. Finally I got a working local build, but team members already merged a few updates onto mainline that created conflicts. I rebased my feature branch onto mainline's HEAD and fixed the conflicts in each local commit. Time to post pull requests for the fixes. I noticed a few of them were related so it would be preferable they went in before everything else. I did an interactive rebase to reorder local commits to move these bugfix commits to the start of the local branch. I squashed them, cleaned them up, and posted a pull request. The pull request was merged into mainline and in the meantime other PRs went in as well. I rebase the remaining commits in the local branch. Followed the same process for another bug. Rinse and repeat. Finally all I had left was the fix for the original issue. I rebased the remaining commits onto mainline, cleaned them up, and posted a PR. Done. One ticket, around 3 PRs, and almost a 1:1 ratio of rebase-to-PR. And here you are, saying rebasing doesn't bring any real value. I think those who complain about rebase are overrepresented by the subset of Git users who barely go beyond the very basic features of checking out branches, pulling changes, and committing stuff. They have no idea how and why other features work, so they complain about things they know nothing about. When pressed about basic usecases, they fall back to trying to fill in the holes in their reasoning by arguing that workflows should be different or that other features are similar, while completely ignoring that features like rebase do the job and do the job very well and very easily.

deleted 3y ago
[deleted]