As someone who has been on a maintenance team for years and regularly has to dig through the history to figure things out, I strongly prefer the original "bad" version with 7 individual commits. Yes "git blame" takes a little bit of extra work to get through all the commits, but knowing what initial mistakes were made and refactors done makes it much easier to tell what the original intent was.
For example, if "fix bob review", "fix alice review", or "minor" introduced something that wasn't noticed until later, by having them separate we can tell whether it was intended functionality or a bug. This has happened to us a whole bunch of times with rarely seen edge cases, so the bug wasn't found until years later, or some other part of the code was masking the issue so it didn't manifest as a bug until years later. At least one of these was even caused in a "linting" commit, and all of these were much more easily fixable because we could tell the bug was introduced in one of these code-review-update commits, rather than the core feature commit.
This is solving the problem with the wrong tool. What you need is documentation. But people working on the project you have to maintain didn't write one. So, you are trying to use git blame, astrology and ouija board to guess what the project authors wanted.
And, while doing so, you are arguing for never cleaning the house, keeping all the garbage where it falls. Which will only make your situation worse, because the history will bloat with a lot of contradictory or false information.
> What you need is documentation. But people working on the project you have to maintain didn't write one.
Oh there is documentation, but it's old and contradictory. Commits are self-organizing by history.
> So, you are trying to use git blame, astrology and ouija board to guess what the project authors wanted.
There's no guessing involved. Keep the original commits and it's right there in the commit message and order of changes.
Guessing is what happens when you destroy the history by using rebases like this.
> And, while doing so, you are arguing for never cleaning the house, keeping all the garbage where it falls. Which will only make your situation worse, because the history will bloat with a lot of contradictory or false information.
I'm not saying "don't refactor" at all. Clean the code up as much as you want. The history however is completely hidden and not causing any clutter, it's there when you need it and invisible the rest of the time, so erasing useful history is just busywork for negative benefit.
Any apparent contradictions are also easily resolved because commits have timestamps and ordering and are part of the larger completely automatically generated history.
> Oh there is documentation, but it's old and contradictory.
That's like saying "oh, but I have food to eat, except it's been eaten by mice and mold. I mean, if documentation doesn't work, then it's the same as "no documentation"...
> There's no guessing involved.
But that's where you are wrong. The more garbage isn't cleaned from the repository, the more guessing you have to do. What if a comment next to the code contradicts the code? -- It's garbage! But nobody cleaned it, and now you have to guess whether the comment or the code is correct. But this is just an easy-to-understand example. Essentially, any bug is like this: there was an intention to do X, but Y was done instead, and now you need to figure out whether Y was intended or X.
History needs to make sense, it doesn't need to document the mistakes that happened along the way. Not for the purpose of development anyways.
> Clean the code up as much as you want. The history however is completely hidden and not causing any clutter,
I'm not talking about refactoring code, I'm talking about cleaning the history. It's only hidden if you are completely hapless when it comes to working with Git. Any developer worth their salt work with the history regularly. It's not a secret, and it's definitely not hidden.
On the contrary, if you believe history to be "invisible" -- just use rsync. There's no need for complicated system that's designed to work with history... If you cannot make use of your history -- why bother keeping it?
I don't know why people are so happy to throw out the history. I find it's not uncommon that bugs are introduced during rebasing, and merging in from master. Sometimes this is due to incorrectly resolved conflicts, sometimes due to concurrent changes elsewhere in the codebase.
With --first-parent it isn't hard to have your cake (full history) and eat it too (linear mainline history).
For example, if "fix bob review", "fix alice review", or "minor" introduced something that wasn't noticed until later, by having them separate we can tell whether it was intended functionality or a bug. This has happened to us a whole bunch of times with rarely seen edge cases, so the bug wasn't found until years later, or some other part of the code was masking the issue so it didn't manifest as a bug until years later. At least one of these was even caused in a "linting" commit, and all of these were much more easily fixable because we could tell the bug was introduced in one of these code-review-update commits, rather than the core feature commit.