5 ms·

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that of

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not strive to do this. It allows it, to some degree. This is not the same thing at all and is basically FUD. I would say the debate is ongoing as to the value of history rewriting. It's probably a tradeoff that some orgs are willing to leverage and Fossil is masking that they allow less flexibility in workflows as an obvious advantage, feels slimy.

bloopernova 3y ago
Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.
- bradley13 3y ago
  I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.
  - Kamq 3y ago
    Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.
  - snuxoll 3y ago
    Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.
    - kaashif 3y ago
      Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine. Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense. Both result in the same diff from master so are equivalent for submitting a patchset. It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.
      - _ikke_ 3y ago
        Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.
  - goku12 3y ago
    There are a few legitimate cases where you want to rewrite history. 1. Assume you are a user who is cloning the master/main branch and building it. If that branch contains your development missteps, then you are in for a world of pain. We as users always assume that the master/main Head is always buildable (excluding inadvertent mistakes). 2. If you are sending the commits as patches, then it makes sense to include a complete feature in a single patch. It will otherwise be very hard for the reviewer to make sense of any patch.
  - rewmie 3y ago
    > I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? There are plenty of reasons if you're doing non-trivial tasks on local branches within a team. I've mentioned a common usecases I have, which is to reorder commits I make in local branches to afterwards peel them off as stand-alone pull requests.
moojd 3y ago
I like that git allows rebase, as long as it is only done in prs or local. Rebase in the sheets, merge in the streets.
- twic 3y ago
  Or, more conventionally put: > The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... If you're doing trunk based development, with continuous integration, then you're approximately always on a public branch, and rebasing is not very useful.
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.
nerdyadventurer 3y ago
Forgive my dumb question, how do you avoid rebase (ex: when making PR)?
- Supermancho 3y ago
  Generally you merge main into your branch to resolve the conflicts there, then push to make the PR. Sometimes it's easier to rebase, sometimes easier to merge your main. The frequency of one or the other being more useful/easier often influences the accepted workflow.

bloopernova 3y ago

Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.

bradley13 3y ago
I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.
- Kamq 3y ago
  Usually it's if you committed something you shouldn't have. You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.
- snuxoll 3y ago
  Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes. There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well. The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.
  - kaashif 3y ago
    Rebasing to squash commits or even split commits up before/during making a PR makes sense to me and I do it all the time just to clean up my mess. The order of development and the state of the repo over time isn't faked, this is just labelling and granularity. What doesn't make sense to me is rebasing instead of merging. If master has a lot of changes and you want to pick those up, you can merge in which case history reflects reality - each commit has an actual state of the repo that you had on your machine. Or you can rebase, in which case all of the commits on your branch now contain code that no-one ever had on their machine, not tested, never run, maybe it doesn't compile, maybe it's nonsense. Both result in the same diff from master so are equivalent for submitting a patchset. It's really hard for me to see the value of trashing your history like that. People like linear history but history actually is not linear sometimes.
    - _ikke_ 3y ago
      Lots of criss-cross merges make it really difficult to follow history, making it less useful. Note that merge vs rebase a false dichotomy. After rebasing you still have to merge your branch anyway, either fast-forward or with an explicit merge commit. In the end, it's about commutating your changes effectively. The less noise there is, the better you can communicate. That takes effort from both sides, but many persons put all the burden on the receiving side.
- goku12 3y ago
  There are a few legitimate cases where you want to rewrite history. 1. Assume you are a user who is cloning the master/main branch and building it. If that branch contains your development missteps, then you are in for a world of pain. We as users always assume that the master/main Head is always buildable (excluding inadvertent mistakes). 2. If you are sending the commits as patches, then it makes sense to include a complete feature in a single patch. It will otherwise be very hard for the reviewer to make sense of any patch.
- rewmie 3y ago
  > I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? There are plenty of reasons if you're doing non-trivial tasks on local branches within a team. I've mentioned a common usecases I have, which is to reorder commits I make in local branches to afterwards peel them off as stand-alone pull requests.

moojd 3y ago

I like that git allows rebase, as long as it is only done in prs or local. Rebase in the sheets, merge in the streets.

twic 3y ago
Or, more conventionally put: > The golden rule of git rebase is to never use it on public branches. https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing https://www.atlassian.com/git/tutorials/merging-vs-rebasing#... If you're doing trunk based development, with continuous integration, then you're approximately always on a public branch, and rebasing is not very useful.

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.

nerdyadventurer 3y ago

Forgive my dumb question, how do you avoid rebase (ex: when making PR)?

Supermancho 3y ago
Generally you merge main into your branch to resolve the conflicts there, then push to make the PR. Sometimes it's easier to rebase, sometimes easier to merge your main. The frequency of one or the other being more useful/easier often influences the accepted workflow.