5 ms·

I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed comm

I think you underestimate just how much stupid garbage I have in my commit history. It's embarrassing. Even if you squash when merging the PR, the squashed commit message is gonna have a ton of messages that look like "Why the hell isn't this compiling?", "wtf?", "FINALLY PASSES!" etc etc etc. I could avoid creating those commits in the first place, but asking me to only commit my local changes when I have something intelligent to say about them, is a damn near impossibility for me. I basically use git to "save my work" before I try an approach to something. I reset back if it doesn't work out. Sometimes I reset back again, if the approach that didn't work out turned out to be the least worst option. I create commits to experiment with something, so that I can quickly compare back and forth between two approaches. etc. etc. etc. I would instead say, that if you're only making commits when you have something logical to say, you're probably not using git to its fullest potential. You should really go nuts with it IMO, and only bother to sound intelligent in your commit messages once you're ready to do so, and (most importantly) you should still make commits before that happens. Git's decentralized for a reason, take advantage!

kristaps 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        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 5y ago
        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.
ojkelly 5y ago
You can remove those messages from the final commit when you squash. If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr.
- ninkendo 5y ago
  > If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr. I agree! And that's what I do. But OP said that would be "a waste of time and effort", hence my reply.

kristaps 5y ago

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 5y ago
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 5y ago
  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 5y ago
    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 5y ago
      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 5y ago
        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 5y ago
        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.

ojkelly 5y ago

You can remove those messages from the final commit when you squash. If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr.

ninkendo 5y ago
> If someone else is doing the merge and you’re unsure if they will you can preemptively squash your whole branch so there’s only one commit in the pr. I agree! And that's what I do. But OP said that would be "a waste of time and effort", hence my reply.