[kristaps]

It's true that messy commits happen, that's why squash is there.

Nothing forces you to keep the messy commit messages either - keep the short commit message and make sure it's good, then delete the combined individual commit messages from the long message field, done.

[ninkendo]

My point is that I don't want anyone to see my WIP commits in the first place. Squashing only in the end when merging to master means the code reviewers get to see my messy commit history, which is what I'm trying to avoid. (Yes, my commit history is that bad that it's embarrassing. But at least I commit early and often, which has saved my ass more times than I can count.)

[digisign]

Not in gitlab at least. Click on squash and you see nothing but the total of the branch difference, the merge req title, and a few lines of boilerplate it adds.

About as easy as it gets. As titles are issue numbers changes are documented automatically.

[ninkendo]

I don’t want anybody to be able to see my WIP commits, even if it’s easy for them not to see them.

Yes, that probably is a “me” problem, and I’m too anxious about it for no reason, but that’s me. But if you saw my local scratch branches you’d probably understand.

(My wip commits occasionally bitch about coworkers, for example. Or they just contain a bit too much profanity for a professional environment. Or there’s just 50 worthless “WIP” commits with no other description. You’d never know any of this from my PRs.)

[digisign]

Recording sensitive information then relying on your perfect performance to remove it is flawed opsec. Not to mention a waste of time, as our great ancestor mentions.

[ninkendo]

It’s not a career ending thing if somebody saw my commit history. It’s just mildly embarrassing. It’s not a waste of time either… time spent crafting a final commit from the whole change, writing a descriptive commit message, and documenting everything well helps people review it, and that’s time well spent.

[digisign]

Ok, that's one strategy. However, we put that information in our issue tracker, docs, and source code comments, where more people can reach them more easily. Commit msg is PROJ-1234, which gets automatically gets linked to issue with design and comment history and project/product folks can contribute.

[_hao]

Why not create a new branch (let's call it B) from your messy branch (call it A) and squash everything in B before raising a PR from B -> master

That will solve your problems if you're the messy type.

[ninkendo]

Sure, that’s exactly what I’m advocating for? I’m confused.

You said it’s a waste of time to do this and to just squash when merging instead. I’m saying I’d rather squash first so that my PR looks clean and doesn’t contain my WIP commits. Then you respond saying “well you can just squash before your PR then”… are we going in circles?

[_hao]

Your use case is a bit different than what the article is arguing for. If you have a personal preference to have everything shown as a single commit in the PR by all means do things the way outlined above.

My original comment was targeting the two supposed problems that the article is framing and the supposed convoluted (and possibly dangerous) solution with git reset.