5 ms·

Once I read "this is ugly and pollutes your history graph" as a justification for any git feature, I'm immediately turned off. What really is wrong with having

by derriz 7y ago

Once I read "this is ugly and pollutes your history graph" as a justification for any git feature, I'm immediately turned off. What really is wrong with having a graph that actually reflects the real history of changes as they were made at the time? Why not keep things simple and improve git-log so that anything you find ugly or that looks like pollution can be hidden while viewing the history of a repo? In this case, for example, would it not be far more ergonomic to add a "--hide-control-merges" flag to git-log? This rerere feature described looks like a lot of the foot-guns git provides. I know I'm in a minority here - I've given up arguing with collegues that it's possible to have a branch&merge work-flow without constant re-basing. Allowing the history graph to be manipulated and changed seems to have become part of the most popular git work-flows even though it's a recipe for serious pain in a distributed VCS. (This isn't a criticism of the article btw - more of the git design/philosophy.)

michaelgrafl 7y ago
I don't see how rebasing often and keeping a linear history is in any way a worse workflow than letting merge bubbles happen. To the contrary, I've changed my preferences from the latter to the former because it turned out to be more readable and to make it easier to find commits that introduced bugs or contain badly done merges.
- derriz 7y ago
  If there's more than one person working on the code base, rebasing is only safe if you restrict pushing/pulling in some way. Properly interleaving pushes and rebases is just more mental load and another way to shoot yourself in the foot with git. And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. But like I said, I've given up arguing about it and have reluctantly embraced my inner rebaser. A small part of me still feels it's a regression.
  - einpoklum 7y ago
    If your rebasing only rewrites history up to a point that's shared by everyone working on the same branch as you, I don't see what's the big problem. > And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. You haven't, others (like me) have...
  - dahart 7y ago
    If your team is rebasing already public history, then you’re right. Is that what you’re talking about? History should be cleaned up locally before pushing elsewhere. Once pushed, history shouldn’t be rewritten except in emergencies, and even then it should be discussed and communicated and everyone should agree a rewrite is better than more pushes to fix the problem. A case where a rewrite is preferable is when someone accidentally checks security keys into git, for example. Rebasing before pushing should be embraced, are you sure that’s not the majority of what’s happening?
    - jayd16 7y ago
      The issue is its easy to screw up this advice. This is like saying only look down the barrel of a gun if you know its not loaded.
      - dahart 7y ago
        How so? And which part? I think it’s difficult to rebase already pushed history accidentally, because that requires a force push. You have to opt-in and take action to do it, so it’s not easy to screw up unintentionally.
        jayd16 7y ago
        Well you can say having to force is a solid barrier but you'll see plenty of comments suggesting that as well as plenty of comments stemming from having had to clean it up.
        dahart 7y ago
        Sure, but that’s completely different from your hyperbolic analogy of looking down the barrel of an unloaded gun. Force push has a solid barrier, it is not default behavior, it gives you warnings, the manual gives warnings, and if you read anything online you’ll find many warnings against. If people still do it not knowing what they’re doing, yes it can definitely cause problems, but you can’t call it an accident or easy to screw up.
GauntletWizard 7y ago
It's ultimately a tooling problem - Git doesn't have a good way of "tagging" feature branches to be ignored. It's concept of branches is limited - There's only places where there's more than one parent commit, and which is which is unclear. If you handle it badly, you end up with an unreadable history, littered with 'f' commits and junk, rather than having a nice linear history you can run regressions on. I don't think this is a problem with Git, per-se - I think it's a problem with the tooling we use to interpret it, and the tooling we use to commit to it. But there's a lot of "valid but invalid" ways you can use it, and writing good tooling for different flows is hard, so nobody's invested in it a bunch.
toupeira 7y ago
To get the best of both worlds: You could use normal merges while working on a branch, and then when it's done do one rebase (which also removes merge commits) before merging back into master.
dahart 7y ago
Edit here at the top to clarify: I’m talking about rebasing your own commits before pushing. It sounded like the parent comment was talking about blanket use of rebase. I don’t advocate rebasing other people’s pushed commits, other than a few very exceptional circumstances. > What is really wrong with having a graph that actually reflects the real history of changes as they were made at them time? You’re inflicting irrelevant noise and cognitive load on yourself and other people. Noise in the history can also cause all kinds of trouble with merges and with bisect and other git features. A clean history is easier to work with. Given that Linus advocates rebasing to clean the repo history, I’m curious where the whole “we must preserve the real history”, and dogmatic belief that messy history is some sort of “correct” git design/philosophy. There is no “real” history. Commit order is arbitrary, especially between orthogonal changes by different people. Anything you modify later using rebase can (and is) done before rebase. There is no sacred set of events to preserve, and it has real and practical ramifications to let the repo get messy when you’re on a large team. Why not embrace the idea of preserving the semantic history, the intent, as cleanly and clearly as possible, rather than focus on preserving arbitrary noise that doesn’t mean anything to you, let alone others? > I’ve given up arguing with colleagues that it’s possible to have a branch & merge work-flow without constant re-basing. It is possible, but it’s not desirable. > Allowing the history graph to be manipulated and changes seems to have become part of the most popular git work-flows even though it’s a recipe for serious pain in a distributed VCS. Would you elaborate on what pain you’re talking about? Rebasing is something that happens before push to master, if you’re using it properly, and that’s what the article here is talking about. If anyone’s rebasing the remote’s branches, that is bad, but that is not common practice. Aside from that, you’re talking about git design and failing to acknowledge that rebase and manipulating the graph history is the design of git. Updating local history is a good thing, and it was designed that way intentionally.
- derriz 7y ago
  I completely agree that rebase and manipulating the graph history is part of the design of git. But also you can use git effectively without manipulating the history (in a non-incremental way). And you don't lose anything in terms of branching and merging - in fact you gain in terms of safety and simplicity in a distributed system. The argument I guess is about what you consider the cost of inflicting "irrelevant noise and cognitive load" on other users. I believe it's not significant and is mostly a function of the deficiencies of the history browsing tooling. On the other hand, I believe that the cost of making rewriting history part of the workflow is significant in terms of the load it places on users to learn features like rerere, for example. If I've understood you correctly then I think neither of us can be right or wrong - it depends what each of us considers a greater "cognitive load" or cost which is going to be based on our personal experiences and preferences rather than something empirical.
notus 7y ago
Because a git history is meant to be read efficiently

by derriz 7y ago

michaelgrafl 7y ago

I don't see how rebasing often and keeping a linear history is in any way a worse workflow than letting merge bubbles happen. To the contrary, I've changed my preferences from the latter to the former because it turned out to be more readable and to make it easier to find commits that introduced bugs or contain badly done merges.

derriz 7y ago
If there's more than one person working on the code base, rebasing is only safe if you restrict pushing/pulling in some way. Properly interleaving pushes and rebases is just more mental load and another way to shoot yourself in the foot with git. And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. But like I said, I've given up arguing about it and have reluctantly embraced my inner rebaser. A small part of me still feels it's a regression.
- einpoklum 7y ago
  If your rebasing only rewrites history up to a point that's shared by everyone working on the same branch as you, I don't see what's the big problem. > And I don't see the point just to get prettier git-log output - I've never had an issue finding commits or diffing across more than one commit. You haven't, others (like me) have...
- dahart 7y ago
  If your team is rebasing already public history, then you’re right. Is that what you’re talking about? History should be cleaned up locally before pushing elsewhere. Once pushed, history shouldn’t be rewritten except in emergencies, and even then it should be discussed and communicated and everyone should agree a rewrite is better than more pushes to fix the problem. A case where a rewrite is preferable is when someone accidentally checks security keys into git, for example. Rebasing before pushing should be embraced, are you sure that’s not the majority of what’s happening?
  - jayd16 7y ago
    The issue is its easy to screw up this advice. This is like saying only look down the barrel of a gun if you know its not loaded.
    - dahart 7y ago
      How so? And which part? I think it’s difficult to rebase already pushed history accidentally, because that requires a force push. You have to opt-in and take action to do it, so it’s not easy to screw up unintentionally.
      - jayd16 7y ago
        Well you can say having to force is a solid barrier but you'll see plenty of comments suggesting that as well as plenty of comments stemming from having had to clean it up.
        dahart 7y ago
        Sure, but that’s completely different from your hyperbolic analogy of looking down the barrel of an unloaded gun. Force push has a solid barrier, it is not default behavior, it gives you warnings, the manual gives warnings, and if you read anything online you’ll find many warnings against. If people still do it not knowing what they’re doing, yes it can definitely cause problems, but you can’t call it an accident or easy to screw up.

GauntletWizard 7y ago

It's ultimately a tooling problem - Git doesn't have a good way of "tagging" feature branches to be ignored. It's concept of branches is limited - There's only places where there's more than one parent commit, and which is which is unclear. If you handle it badly, you end up with an unreadable history, littered with 'f' commits and junk, rather than having a nice linear history you can run regressions on. I don't think this is a problem with Git, per-se - I think it's a problem with the tooling we use to interpret it, and the tooling we use to commit to it. But there's a lot of "valid but invalid" ways you can use it, and writing good tooling for different flows is hard, so nobody's invested in it a bunch.

toupeira 7y ago

To get the best of both worlds: You could use normal merges while working on a branch, and then when it's done do one rebase (which also removes merge commits) before merging back into master.

dahart 7y ago

Edit here at the top to clarify: I’m talking about rebasing your own commits before pushing. It sounded like the parent comment was talking about blanket use of rebase. I don’t advocate rebasing other people’s pushed commits, other than a few very exceptional circumstances. > What is really wrong with having a graph that actually reflects the real history of changes as they were made at them time? You’re inflicting irrelevant noise and cognitive load on yourself and other people. Noise in the history can also cause all kinds of trouble with merges and with bisect and other git features. A clean history is easier to work with. Given that Linus advocates rebasing to clean the repo history, I’m curious where the whole “we must preserve the real history”, and dogmatic belief that messy history is some sort of “correct” git design/philosophy. There is no “real” history. Commit order is arbitrary, especially between orthogonal changes by different people. Anything you modify later using rebase can (and is) done before rebase. There is no sacred set of events to preserve, and it has real and practical ramifications to let the repo get messy when you’re on a large team. Why not embrace the idea of preserving the semantic history, the intent, as cleanly and clearly as possible, rather than focus on preserving arbitrary noise that doesn’t mean anything to you, let alone others? > I’ve given up arguing with colleagues that it’s possible to have a branch & merge work-flow without constant re-basing. It is possible, but it’s not desirable. > Allowing the history graph to be manipulated and changes seems to have become part of the most popular git work-flows even though it’s a recipe for serious pain in a distributed VCS. Would you elaborate on what pain you’re talking about? Rebasing is something that happens before push to master, if you’re using it properly, and that’s what the article here is talking about. If anyone’s rebasing the remote’s branches, that is bad, but that is not common practice. Aside from that, you’re talking about git design and failing to acknowledge that rebase and manipulating the graph history is the design of git. Updating local history is a good thing, and it was designed that way intentionally.

derriz 7y ago
I completely agree that rebase and manipulating the graph history is part of the design of git. But also you can use git effectively without manipulating the history (in a non-incremental way). And you don't lose anything in terms of branching and merging - in fact you gain in terms of safety and simplicity in a distributed system. The argument I guess is about what you consider the cost of inflicting "irrelevant noise and cognitive load" on other users. I believe it's not significant and is mostly a function of the deficiencies of the history browsing tooling. On the other hand, I believe that the cost of making rewriting history part of the workflow is significant in terms of the load it places on users to learn features like rerere, for example. If I've understood you correctly then I think neither of us can be right or wrong - it depends what each of us considers a greater "cognitive load" or cost which is going to be based on our personal experiences and preferences rather than something empirical.

notus 7y ago

Because a git history is meant to be read efficiently