3 ms·
Most developers I've worked with think of Git as a CLI front-end to GitHub. They aren't writing commits with the intention of showing their work, they are usin
by alphazard 3y ago
Most developers I've worked with think of Git as a CLI front-end to GitHub. They aren't writing commits with the intention of showing their work, they are using commits to save their work before signing off, or to trigger CI. They aren't proficient enough with Git to go back over these and clean them up, as would be expected in a project like the Linux kernel.
If that's the state of developer proficiency with version control then, ideal workflows aside, we need a way to prevent those noise commits from ending up in master, and the easiest way is to squash with every pull request, as part of the "merge" automation.
- burntsushi 3y agoWhy do you need to squash & merge literally every PR? Why not use squash & merge when appropriate and rebase & merge otherwise? That's what I do for my projects. Most contributions coming from others tend to get squashed & merged, where as I'll rebase & merge my commits. But I'll sometimes rebase & merge PRs from other contributors who have broken their change down into thoughtful commits.
- kdmccormick 3y agoThis is it. The real answer to this whole debate is "it depends" but for some reason that doesn't seem to satisfy people.
- rokkitmensch 3y agoThe effective management approach (in opposition to the limp-souled "servant leader" anemia) is to make decisions for your team to eliminate stupid work. What, you're going to let anyone waste time on tabs versus spaces?
- burntsushi 3y agoYou've presupposed that this is all about stupid stuff in the first place. Moreover, mixing tabs and spaces for indentation leads to sadness. But squash and rebase are perfectly compatible with over another. Programmers sometimes have to decide stuff. That's okay.
- alphazard 3y ago> Why do you need to squash & merge literally every PR? Why not use squash & merge when appropriate and rebase & merge otherwise? "When appropriate" is the key here. That's asking people to make a decision, take on additional cognitive load, which does not have a clear deliverable or success criteria. In practice the default is what happens.
- burntsushi 3y agoWe need to make decisions about code and maintainability all the time. I don't see why this is any different.
- rokkitmensch 3y agoEvery opportunity to eliminate cognitive overhead is a win for the team. As I say to my children on the reg, "What's the best way to clean up a mess? Don't make it in the first place."
- brayhite 3y agoAs my children repeatedly prove: one person’s “not a mess” is another person’s disorganized chaos.
- burntsushi 3y agoTelling my child not to make a mess so he can avoid cleaning it up would not be an effective tactic at anything other than acting smug. You're presupposing that this decision is worth making for programmers in the first place. I don't see why that ought to be true.