8 ms·

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone wor

by davedx 3y ago

I’ve never understood the tradeoff of rebasing, squashing or otherwise “keeping a clean history”. It always seemed like tons of sometimes highly error prone work (sometimes you can wipe out a colleague’s work with it! Wtf!), for almost no gain (why does it matter that the git history is “clean”?).

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
- 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.
renewiltord 3y ago
It's for humans. You can more easily cycle to a specific point. I find linear history easier to comprehend. But it's not like a game ender. People will do whatever they will. I find it easier to run git binary search with it like this too.
pm215 3y ago
For me the big gain is at the code review stage. It's much easier to review a set of patches that are a clear and distinct sequence of changes without "oops, fix bug" changes later in the series. It does require extra work by the code author, but it means less work for the code reviewer. Depending on the project and the organisation and the workflow, that can be a worthwhile tradeoff.
paulddraper 3y ago
> keeping a clean history This being a principal reason for VCS, I very much understand the motivation.
- naasking 3y ago
  "Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.
  - paulddraper 3y ago
    Part of not losing stuff and reverting is being able to find stuff and precisely revert.
  - rhinoceraptor 3y ago
    There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.
    - naasking 3y ago
      Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
      - seba_dos1 3y ago
        There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.
nicolaslem 3y ago
Sometimes when working on an old code base built by developers that came and went, one needs to perform what I call "code archeology": going back in time to understand why a feature was implemented the way it was. Whether this is feasible at all depends largely on the care developers put in structuring their commits.
- ohwellhere 3y ago
  Yes! The source code is itself the first level of documentation. The commit history is the second. A free form textual interface to document everything about why you made the changes you just made? Why not maximize the value of this resource!
- Izkata 3y ago
  This has become a large chunk of my job over the past few years, as part of fixing/upgrading systems no one has touched in a decade, and none of those original people are still here. There are some weird things in there I've only been able to figure out because all the svn history still exists.
scintill76 3y ago
> sometimes you can wipe out a colleague’s work with it! Wtf! I’m not necessarily on Team Rebase, but isn't this just as likely with merging gone wrong?
- btilly 3y ago
  Not nearly as badly. A badly done merge can indeed ruin code. But you'll always have the versions that went into the merge, and the merge itself. Your history has all of the information to recreate exactly what happened, find what changed, and then figure out how to fix it. A badly done rebase not only ruins your work, it also removes from the branch any record of your work having been done. Unless you can find the right stray old commit which is not yet cleaned up, there is no choice but to start doing it again from scratch.
- deleted 3y ago
  [deleted]
nemetroid 3y ago
It matters because when I: * use filtering commands like "git log -S" * press the "annotate" button in my IDE and can see which commit introduced each line * run "git bisect" * use "tig" to drill down through the history of a file (shortcut "," is "move to commit preceding current line's blame commit") ...every step of the way, I get a meaningful description of why a change was made and what other diffs were necessary to achieve that change. And not just "fix", "bug", "PR commments".
- nomel 3y ago
  > * press the "annotate" button in my IDE and can see which commit introduced each line In PyCharm, I can see which commit introduced each line, regardless of branching. Same with drilling down through a files history. Is this an IDE limitation you're seeing? > every step of the way, I get a meaningful description of why Isn't this more about commit messages, than anything else?
  - nemetroid 3y ago
    The context of my comment is the usefulness of a clean history, not about merging vs rebasing. > Is this an IDE limitation you're seeing? I'm using Jetbrains too.
- WorldMaker 3y ago
  * `git log --first-parent -S` * `git blame --first-parent` * `git bisect --first-parent` * At least one "tig-like" with a --first-parent first UI: https://github.com/kalkin/git-log-viewer https://github.com/kalkin/git-log-viewer
  - seba_dos1 3y ago
    --first-parent is incredibly useful, but having both merge commits and properly curated atomic commits under them is even more useful.
bilalq 3y ago
When an engineer made a change is of no consequence to me. When it got merged into the main branch does matter a whole lot if you're doing trunk-based development.
heisenberg302 3y ago
Another thing is if you keep commits in a clean "state", it is easier to revert a commit, when you squash or keep them messy it can make it harder to revert. Also sometimes you decide you want to backport some change to other releases, and if commits are in a good state, it is much easier to do this.
tuckerpo 3y ago
> why does it matter that the git history is “clean”? Makes reviewing a set of changes prior to a merge much easier. It's nice if there's a 1:1 correlation between a commit message and the actual patch contents. Im sure you've dealt with the case of reviewing a colleague's changes with a commit message like "Enable logging in foobar module" and the patch is actually enabling foobar logging and a bunch of other stuff. This makes bisecting your git history to identify and fix bugs much more difficult. If the git history is clean, you can just read the commit messages and implicitly trust the developer if clean git hygiene is in place (as opposed to actually needing to read the whole diff on a per-commit basis to find out what _actually_ happen at commit XYZ, despite it's message).
bregma 3y ago
It makes your git graph instagrammable.

by davedx 3y ago

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
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.

renewiltord 3y ago

It's for humans. You can more easily cycle to a specific point. I find linear history easier to comprehend. But it's not like a game ender. People will do whatever they will. I find it easier to run git binary search with it like this too.

pm215 3y ago

For me the big gain is at the code review stage. It's much easier to review a set of patches that are a clear and distinct sequence of changes without "oops, fix bug" changes later in the series. It does require extra work by the code author, but it means less work for the code reviewer. Depending on the project and the organisation and the workflow, that can be a worthwhile tradeoff.

paulddraper 3y ago

> keeping a clean history This being a principal reason for VCS, I very much understand the motivation.

naasking 3y ago
"Clean history" is not a principal reason for VCS. "Full history so you don't accidentally lose something and can revert to any point" is the principal reason. When "clean history" conflicts with "full history", the choice should always defer to the latter. Rebase clearly breaks the full history principle.
- paulddraper 3y ago
  Part of not losing stuff and reverting is being able to find stuff and precisely revert.
- rhinoceraptor 3y ago
  There is obviously a point where you do not want full history. For example, it would absurd to use your editor's undo history tree with keystroke level granularity as your VCS, because in most of those points in history, the code won't even compile because you were in the middle of typing a word. If your goal is to be able to revert the codebase to a previous version, then you want your history to a series of well prepared, atomic changes where at each point the software is actually functional.
  - naasking 3y ago
    Clearly that's the reason you make a commit to begin with. Erasing that commit history is just silly.
    - seba_dos1 3y ago
      There are a lot of reasons to make a commit other than wanting to make an atomic change meant to be integrated onto shared repository. Ignoring those is just silly.

nicolaslem 3y ago

Sometimes when working on an old code base built by developers that came and went, one needs to perform what I call "code archeology": going back in time to understand why a feature was implemented the way it was. Whether this is feasible at all depends largely on the care developers put in structuring their commits.

ohwellhere 3y ago
Yes! The source code is itself the first level of documentation. The commit history is the second. A free form textual interface to document everything about why you made the changes you just made? Why not maximize the value of this resource!
Izkata 3y ago
This has become a large chunk of my job over the past few years, as part of fixing/upgrading systems no one has touched in a decade, and none of those original people are still here. There are some weird things in there I've only been able to figure out because all the svn history still exists.

scintill76 3y ago

> sometimes you can wipe out a colleague’s work with it! Wtf! I’m not necessarily on Team Rebase, but isn't this just as likely with merging gone wrong?

btilly 3y ago
Not nearly as badly. A badly done merge can indeed ruin code. But you'll always have the versions that went into the merge, and the merge itself. Your history has all of the information to recreate exactly what happened, find what changed, and then figure out how to fix it. A badly done rebase not only ruins your work, it also removes from the branch any record of your work having been done. Unless you can find the right stray old commit which is not yet cleaned up, there is no choice but to start doing it again from scratch.
deleted 3y ago
[deleted]

nemetroid 3y ago

It matters because when I: * use filtering commands like "git log -S" * press the "annotate" button in my IDE and can see which commit introduced each line * run "git bisect" * use "tig" to drill down through the history of a file (shortcut "," is "move to commit preceding current line's blame commit") ...every step of the way, I get a meaningful description of why a change was made and what other diffs were necessary to achieve that change. And not just "fix", "bug", "PR commments".

nomel 3y ago
> * press the "annotate" button in my IDE and can see which commit introduced each line In PyCharm, I can see which commit introduced each line, regardless of branching. Same with drilling down through a files history. Is this an IDE limitation you're seeing? > every step of the way, I get a meaningful description of why Isn't this more about commit messages, than anything else?
- nemetroid 3y ago
  The context of my comment is the usefulness of a clean history, not about merging vs rebasing. > Is this an IDE limitation you're seeing? I'm using Jetbrains too.
WorldMaker 3y ago
* `git log --first-parent -S` * `git blame --first-parent` * `git bisect --first-parent` * At least one "tig-like" with a --first-parent first UI: https://github.com/kalkin/git-log-viewer https://github.com/kalkin/git-log-viewer
- seba_dos1 3y ago
  --first-parent is incredibly useful, but having both merge commits and properly curated atomic commits under them is even more useful.

bilalq 3y ago

When an engineer made a change is of no consequence to me. When it got merged into the main branch does matter a whole lot if you're doing trunk-based development.

heisenberg302 3y ago

Another thing is if you keep commits in a clean "state", it is easier to revert a commit, when you squash or keep them messy it can make it harder to revert. Also sometimes you decide you want to backport some change to other releases, and if commits are in a good state, it is much easier to do this.

tuckerpo 3y ago

> why does it matter that the git history is “clean”? Makes reviewing a set of changes prior to a merge much easier. It's nice if there's a 1:1 correlation between a commit message and the actual patch contents. Im sure you've dealt with the case of reviewing a colleague's changes with a commit message like "Enable logging in foobar module" and the patch is actually enabling foobar logging and a bunch of other stuff. This makes bisecting your git history to identify and fix bugs much more difficult. If the git history is clean, you can just read the commit messages and implicitly trust the developer if clean git hygiene is in place (as opposed to actually needing to read the whole diff on a per-commit basis to find out what _actually_ happen at commit XYZ, despite it's message).

bregma 3y ago

It makes your git graph instagrammable.