4 ms·
At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top
by pdntspa 3y ago
At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful.
Imagine if it was just lines of ... and "checkpoint" and what not.
If YOU want to go back and clean up after the fact, that's fine. I don't want to do that.
> And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.
That's what I meant about reliability. You CAN trust that dropbox syncs it after a few seconds. You don't need guarantees of atomicity, you just need to be sure that you're only using one machine at a time. Which was an easy rule for me. That is the whole point.
Also, you are very consistently making a lot of assumptions about me and how I work that are incorrect. I suggest you think on this.
- scarface_74 3y ago> At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful. This is against every best practice since I started using git over a decade ago. > You don't need guarantees of atomicity Am I really having this argument in 2023 that you should be using a code syncing process that guarantees atomicity?