Fixing history enables powerful second level tools , such as bisect and cherry pick. Being able to pinpoint a problem to an exact commit is incredibly powerful for debugging, but it does require your commits to be as healthy as possible. If you fix a bug 10 commits after it was introduced , now the 10 commits between them are harder to work with; you always have to keep in mind that unrelated bug. And cherry picking is lovely between branches , but if a commit introduced a bug and another fixes it, now you always have to cherry pick them together. Easier to fix it and keep them atomic.

A clean git history is not a vanity project. It can be used as a tool in further code building.

Bisect still works anyway. For non-huge projects, all this obsession with tool minutiae is a waste of time.

As mentioned by another poster, the fact that a whole website is needed to explain the concept illustrates the design and UI failure.

This is an uphill battle that can't be won until a next-generation interface becomes usable by mortals. If that can't be done due to complexity, it's a lost cause for average developers paid for delivering business value.

You're talking about a UI failure but you're not actually considering the entire experience. Reading the history of the project is a big part of the experience, especially for people in team lead roles. How much of your experience is writing code versus reading code? A merge-oriented workflow often results in a history that is deeply confusing to read. The only part of the experience that you're considering is the authorship of commits, not the utilization of the project's history. I've found a rebase-oriented workflow to result in a significantly more usable repository inasmuch as the history is significantly easier to understand.

History has been useful to me at a high level, inspecting grains of sand at the beach, not so much. I can imagine it might be useful to some like linux kernel devs, but nowhere I've ever worked over a long career.

it's not "inspecting grains of sand". If you have any number of developers worth talking about, merge-oriented workflows can create incredibly unwieldly git histories very quickly. I'm talking about, at a very high level, just understanding the history of the project. If you have five feature branches going on, and your developers are all committing on a regular basis, understanding the history and cadence of your project work based on the git history is incredibly difficult when the events of the separate feature branches are all intermingled.

Your comparison is not apt in many ways. For one thing, open-source governance is extremely different than managing private codebases maintained by a single company. Nobody in open-source governance is reading git histories to figure out whether employees are struggling, who is performing, who is not performing, who is overworking, where the project is, whether or not people are duplicating their efforts, how to report progress to clients, etc. And besides, the Linux kernel uses an email-based, merge-oriented workflow anyway. Kernel patches are submitted via email. That's not at all representative of any company that I have ever worked for or any company that I know of. The Linux kernel history also has a network graph that is literally unviewable on Github because it's so complex. Again, not representative of 95% of the work for 95% of users on 95% of projects.

It's easy enough to select commits from one user, or squash whole branches. Our devs are judged on completed features they deliver at acceptable quality, not their commit history.

I'm not saying you shouldn't care, just that I don't believe this strategy will become mainstream unless it gets much easier to understand and use.

I've heard this before, and it seems reasonable on the surface. The argument I make against this viewpoint is: "git rebase gives us powerful tools that allow us to curate a good commit history in the same way we use refactoring to uphold good software design practices."

My biggest issue with that argument though is what constitutes "good" is subjective. For me a good commit history is one that faithfully chronicles what happened.

With this in mind, acceptable curation of the history for me is squashing or separating commits and neither of these require rebase. But I wouldn't object if a colleague chose to use rebase to accomplish this.

I would, however, object to reordering commits or rebasing since this alters the chronicle.

Which I guess leaves me with my opinion on rebase:

You can, but you don't need to. If you are going to, be sure you understand what you are doing and don't alter the chronicle.

PRs are a good unit of changes for examining meaningful units of changes. No reason to lose info about how the sausage was actually made, it is also a valuable record

Most shops don't follow good software design practices, so how likely is it to get a practice one-step-removed from that, with a difficult UI to boot, adopted?

So you're saying we shouldn't argue for the adoption of good software design practices? There are a lot of software teams that do care, you know.

But this isn't that. It's one step removed. Maybe if the UI gets better. Even then an uphill battle.

Do you use feature branches? Interactive rebases are super nice for cleaning up feature branches before submitting a PR because no one wants to see your broken, non-atomic commits that have swear words in the commit message.

If you submit a PR to my project on GitHub and it consists of 20+ broken, non-atomic commits leading up to the final one, I'm going to ask you to clean them up and squash into one.

What do you use your git history for? History is either worth keeping, in which case you should maintain it like any other artifact, or it's not, in which case you should squash down master to a single commit every time you merge.

But maybe you use your history for something else that I haven't considered.

While I like the idea of rearranging commits to convey a nice (but "not how it originally happened") development sequence, I think in practice this matters less than (say) good commit messages, or the difference between merging and rebasing.

(--fixup type commits aside).

Practical benefits from not squashing history:

- Can bisect to find bug introduction.

- Can annotate/praise/blame to find who/when some change was made.

- Adam Tornhill's "Code as a Crime Scene" argues that it'd be beneficial to consume VCS history to provide health metrics on the codebase. (e.g. use VCS to check which sources have many contributors (thus potentially high defects), or check for "lost knowledge" from developers who have left).

- Can build/run an older version of the software.

But is there really a big advantage from putting time into maintaining a sequence of commits? EDIT: Ah, I see another comment point out that "maintaining a nice history" tends to mean fixing very borked commits. That makes sense. :-)

All of these advantages don't make sense if half your commits are broken versions of the software. Rebasing helps ensure that each commit is valid. That's important for the reasons you mention. Having a log of what you actually did is not important.

History is the cleaned-up story we tell after the fact.

The fact that I had a bunch of stupid typos and broken tests that I didn't realize were broken before I committed doesn't need to be in the final history. What I really want for the preserved history is the conceptual chunks of changes I made along the way.

Is this really good for your team and the project?

If you have a safe work atmosphere, and yor teammates reviewing the work can discover pitfalls in your project's workflow, you as a team can have discussions about it can improve your test stuff. And you can maybe go back through the history and see how many times this kind of normal human mistake with other branches and developers.

You can still diff through the PR as a unit before merging, without getting bogged down in low level commits.

There’s a vast middle ground between those two extremes. Some history is worth keeping, and some is not. Noise commits are of the form “forgot a closing paren,” “comment/uncomment section while debugging,” “finally got it to compile,” “checkpoint,” “fix typo,” or “going home for the day.”

Code and by extension history should be easy for humans to read. For that reason, the signal is very much worth keeping and polishing, but the noise is not. Documentation of false starts, appealing but ultimately problematic design choices, and “why” information belong in comments, commit messages, or design documents — explicit rather than implicitly littered around the history.

can't you do similar by tagging? and then later just diffing against them?

I'm not talking about squashing the feature branch. I'm talking about squashing all of master down to one commit (initial commit). If you don't take care of your history, my question is why do you keep it at all?