You say "two different work flows here" and I think perhaps a better way of considering this is as having multiple _kinds_ of history.

Most of the time, I don't have a clean path through a piece of work such that I can split it out into beautifully concise commits with perfect commit messages. I have WIP commits, messy changes, bad variable names, mistakes, corrections, real corrections, things that I expect everyone does. I commit them every one of them. This is my "private history" or my scratch work.

After I've gotten to the end and I'm satisfied that I've proven my change does what its supposed to do (i.e. tests demonstrate the code), I can now think about how I would communicate that change to someone else.

When I in this stage, it sometimes leads to updating of names now that I'm focussing on communicating my intention. But I figure out how to explain the end result in broad strokes, and subdivide where necessary.

From there, I build "public history" (leveraging all the git tricks). This yields pieces that are digestible and briefly illuminated with a commit message. Some pieces are easy to review at a glance; some take some focus; some are large; some are small.

But key is that the public history is digestible. You can have large, simple changes (e.g. re-namings, package changes) that, pulled out as a separate commit, can be reviewed by inspection. You can have small changes that take focus to understand, but are easily called out for careful attention in a single commit (and divorced from other chaff).

By having these two sorts of history, I can develop _fearlessly_. I don't care what the history looks like as I'm doing it, because I have the power (through my use of git) to construct a beautiful exposition of development that is coherent.

A PR being messy and cluttered is a choice. History can be _easily_ clarified. Anyone who uses git effectively should be able to take a moment to present their work more like framed artwork, and not a finger-painted mess stuck to the refrigerator.

> The commits are imperfect steps along the way.

The workflow you're describing here is fine for staging or stashing or commits that you don't intend to publish. I'll sometimes commit something unfinished, then make changes and either stash those if it doesn't work out, or commit with --amend (and sometimes --patch) to make a single commit that is clean and coherent. The commits aren't always small, but they're meaningful and it's easier to do this along the way than at the very end when it's not so clear or easy to remember all the details from commits that you made days ago.

> It seems some people treat every commit like it's its own little tidy PR

Pull requests are not always "little". But I'm nitpicking.

It sounds like a big difference between the workflows is that you don't amend or stash anything locally along the way. I guess I find it easier and more valuable to edit and squash changes locally into commits before publishing them. Instead of at the very end as a single pull request. For me, I can easily document my process with good commit messages when everything is fresh in my mind.

The end result is that some commits can be pretty big. Sometimes there is no good opportunity to break them down along the way. That is part of the job. But the end result is that these problems concerning a messy history shouldn't be there. The commits I write should be written with the intent of being meaningful for those who might read it. And it's far easier to do that along the way then at the end when it's being merged. So it's difficult to understand some of the complaints people make when they say it's confusing or messy or whatever.

Even if requirements change along the way while the pull request is open, and more commits are added as a response. I've just never had a situation come up where I'm blaming code or something and looking back at the commit history and struggling to understand what was going on in a way where it would be more clear if it had been squashed. Because the commits are already clean and, again, it's just easier to do this along the way.

But again, I use `git commit --verbose --amend --patch` liberally to publish commits intentionally. And that's why it feels like a bit of busywork and violence when people advocate for squashing those.

it is not a philosophical debate against the auto-squash. It is just auto-squash deletes potentially useful data automatically and provides zero benefit? Or what is the benefit?

1. pr message doesn't contain _all_ intent behind each change while the commit did cover the intent behind a technical decision. would you put everything in the pr message? why? it will just be a misleading messy comment for unrelated architectural components.

2. you branch from a wip branch - why? just. - now when the original branch is merged you can't rebase as github/lab messed up the parents.

3. interactive rebase before merge works fine for the wip wip wip style coding. But honestly wip wip wip style happens on bad days, not on days where you are executing a plan.

4. most importantly: you can read the pr message stuff if you filter on merge commits, but if you auto-squash you lose information.