4 ms·

Never understood why you wouldn't want it clean. There's no benefit whatsoever to it being messy and it's a liability for a lot of reasons, whereas the clean ve

by ajkjk 3y ago

Never understood why you wouldn't want it clean. There's no benefit whatsoever to it being messy and it's a liability for a lot of reasons, whereas the clean version is free and easy and makes everything you do that interacts with git history simpler.

haakonhr 3y ago
Is it free though? I'm a fan of rebase myself, but understand the point made above. For me, the biggest pro of a clean history is when doing `git blame`. If the history is clean and the commits are good, it might solve my issue. On the other hand, if the commit in question is a huge mess of unrelated things it doesn't help me at all. I also find it way easier to review a PR with a clean, well-described history.
- ajkjk 3y ago
  Well I also object to multiple unrelated changes in the same commit. Those should be separate commits, and separate code reviews for that matter.
rbehrends 3y ago
You can have it clean without rebasing. This is simply a matter of properly visualizing the history. Unfortunately, most of the major version control systems have decided to basically just dump a raw graph rather than presenting the history in a more user-friendly fashion.
btilly 3y ago
There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never figured out who) in another group would rebase every few weeks. We didn't find out about it until their stuff was pushed then released. The result was that features which we'd written, QAed, and released to production would simply disappear a few weeks later. With no history suggesting that it ever existed. Have you ever been pulled off of a project to go fix a project from a month ago which has disappeared from source control? You don't know what happened, you no longer have context, you've just got complaints because your stuff no longer works. Is your desire for a "clean history" worth potentially creating THAT disaster for other developers on your team???
- diek 3y ago
  The golden rule is "do not rewrite history of a public branch". Rebase/squash your PR branches to your heart's content, but once it's merged that's it. You get clean history by not merging branches with 50 intermediary "fiddling with X" commits in them.
  - btilly 3y ago
    Related, it is a bad idea to use long-running per team branches. Merge early, merge often, get commits to trunk ASAP. With best practices on unit testing, code review, and so on, this scales to many thousands of developers. And will save a lot of pain over time.
- debaserab2 3y ago
  > I used to work at a company where someone (we never figured out who) Wouldn't this be trivially solvable by git bisecting your deploy branch?
  - btilly 3y ago
    No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.
    - deleted 3y ago
      [deleted]
    - lifeisstillgood 3y ago
      Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago? I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB". or am I missing something?
      - 3y ago
unicornmama 3y ago
You can run ‘git log —-first-parent’ that will give you the same output as squash merging, without losing the ability to effectively manage stacked branches/PRs. But because GitHub and other tool’s version of rendering history just flatten merge commits into spaghetti we’re stuck with squash merge. Thanks GitHub.
LAC-Tech 3y ago
I want it clean. But I don't want to do the work to make it clean. The juice is not worth the squeeze.
BeetleB 3y ago
As your parent already said, (and it matches my experience), we didn't have any of these problems when using systems without history rewriting (mercurial, for example). I recall when I first switched to git at work and the team was insisting on a "linear history", I was bemused: Could these developers really not handle a merge graph? It was bizarre how something straightforward in other VCS is suddenly "messy" amongst git folks.
- ajkjk 3y ago
  It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life. It is like moving to one's favorite part of town.
  - BeetleB 3y ago
    > It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life. As someone who has had to put up with rebase for several years now, my life is definitely not better. And things that were trivial in mercurial are now complicated (seeing the actual chronology - both in the log and in the graph). That graph with multiple branches that git developers find messy can actually be really useful.

by ajkjk 3y ago

haakonhr 3y ago

Is it free though? I'm a fan of rebase myself, but understand the point made above. For me, the biggest pro of a clean history is when doing `git blame`. If the history is clean and the commits are good, it might solve my issue. On the other hand, if the commit in question is a huge mess of unrelated things it doesn't help me at all. I also find it way easier to review a PR with a clean, well-described history.

ajkjk 3y ago
Well I also object to multiple unrelated changes in the same commit. Those should be separate commits, and separate code reviews for that matter.

rbehrends 3y ago

You can have it clean without rebasing. This is simply a matter of properly visualizing the history. Unfortunately, most of the major version control systems have decided to basically just dump a raw graph rather than presenting the history in a more user-friendly fashion.

btilly 3y ago

There is a giant benefit to it being messy. And that is that the mess is the actual history. Every time you do a git rebase, you are literally asking your source control system to lie about history. If you mess up, and you eventually will, you're then forced to manually figure out what the history really was despite being lied to. If you mess it up, well, good luck. I used to work at a company where someone (we never figured out who) in another group would rebase every few weeks. We didn't find out about it until their stuff was pushed then released. The result was that features which we'd written, QAed, and released to production would simply disappear a few weeks later. With no history suggesting that it ever existed. Have you ever been pulled off of a project to go fix a project from a month ago which has disappeared from source control? You don't know what happened, you no longer have context, you've just got complaints because your stuff no longer works. Is your desire for a "clean history" worth potentially creating THAT disaster for other developers on your team???

diek 3y ago
The golden rule is "do not rewrite history of a public branch". Rebase/squash your PR branches to your heart's content, but once it's merged that's it. You get clean history by not merging branches with 50 intermediary "fiddling with X" commits in them.
- btilly 3y ago
  Related, it is a bad idea to use long-running per team branches. Merge early, merge often, get commits to trunk ASAP. With best practices on unit testing, code review, and so on, this scales to many thousands of developers. And will save a lot of pain over time.
debaserab2 3y ago
> I used to work at a company where someone (we never figured out who) Wouldn't this be trivially solvable by git bisecting your deploy branch?
- btilly 3y ago
  No, because git bisect operates off of the information in the history. And thanks to the bad rebase, the history no longer existed in the branch.
  - deleted 3y ago
    [deleted]
  - lifeisstillgood 3y ago
    Just clarifying ... they took a version of master from say a month ago, did their work on it, then, they force pushed their work out, wiping everyone else's work that was added to master since one month ago? I mean that's the equivalent of reversing your JCB through a house on a building site because "the house was not there a week ago when I last moved the JCB". or am I missing something?
    - 3y ago

unicornmama 3y ago

You can run ‘git log —-first-parent’ that will give you the same output as squash merging, without losing the ability to effectively manage stacked branches/PRs. But because GitHub and other tool’s version of rendering history just flatten merge commits into spaghetti we’re stuck with squash merge. Thanks GitHub.

LAC-Tech 3y ago

I want it clean. But I don't want to do the work to make it clean. The juice is not worth the squeeze.

BeetleB 3y ago

As your parent already said, (and it matches my experience), we didn't have any of these problems when using systems without history rewriting (mercurial, for example). I recall when I first switched to git at work and the team was insisting on a "linear history", I was bemused: Could these developers really not handle a merge graph? It was bizarre how something straightforward in other VCS is suddenly "messy" amongst git folks.

ajkjk 3y ago
It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life. It is like moving to one's favorite part of town.
- BeetleB 3y ago
  > It's not that we/they 'can't' handle it. It's that we choose not to because it's a better life. As someone who has had to put up with rebase for several years now, my life is definitely not better. And things that were trivial in mercurial are now complicated (seeing the actual chronology - both in the log and in the graph). That graph with multiple branches that git developers find messy can actually be really useful.