> It's equally wrong to rig up a context like that and say that therefore prs should be squashed.
Why? It’s super helpful for me. It makes me a better engineer, and nobody I work with has to care that this is happening, because it’s all gone by the time I make a PR. Why is it “wrong?” Because you have a certain definition in your head about what a commit “is”, and are making a bunch of blanket statement based on this assumption, and everyone who has different assumptions is therefore wrong?
To be fair, I don’t run “git commit” in a loop. I do however, commit extermely early and extremely often. I commit just about every time the code compiles, whether I’m done with what I’m doing or not. Whenever I decide “hmm, approach A isn’t working great, let me try approach B”, I make a commit. If approach B doesn’t work out either, I can compare it with my commit at approach A and decide which elements I want to take from both. I can create branches to do make this easier, so that I can switch between them at will.
The point is, I make commits at what should be considered arbitrary points in time, because for me, a commit doesn’t mean “a thing I want someone to review”. A commit means “I don’t trust my editor not to crash and wipe my undo history, so I’m going to create a checkpoint right now in case of a crash or sudden power loss”. Who are you to judge me for this? Why is it wrong?
> But there is still some point where you do decide "here there is a meaningful milestone" and you mark that spot.
Right, that’s called “a pull request”. It’s the reviewable unit of my productivity. When I decide “here is a thing I believe should be merged”, I put up a PR. I don’t believe this needs to be broken further into the endless commits that it took me to arrive at this point.
> You've just artificially gone out of your way to make your own commits useless for that.
No, I’ve gone out of the way to save my work. Git commit is extremely good at this, because it lets me save my work in a way that supports branches, which my editor’s undo history does not. It lets me compare these units of saved work in a way no editor can (even for editors which support branching undo history.) But with this workflow naturally comes the conclusion that I must squash all of this into one meaningful commit (with a good commit message) once it’s ready to be reviewed. There’s no reason whatsoever that anyone should care that I typed “git commit -am wip” a bunch of times while getting to that point.