This should not be a rule but a guideline IMO. Some PRs do contain commits that reflect trial and errors due to unanticipated build failures.
Gary On Sat, Nov 18, 2023, 6:27 PM Joseph Kessselman <kesh...@alum.mit.edu> wrote: > After discussion (some of it a bit more heated than necessary, > apologies), I am beginning to accept that current wisdom is that pull > requests and merges should _not_ be squashed. The incremental history > within them is worth retaining, especially when multiple people have > contributed to the branch before it is merged back in. > > Unless someone advances a Good Reason for always squashing at merge, I'm > going to try to break myself of that habit, and suggest that we make > avoiding the git squash operation a general policy for the project. It > may or may not have made sense in my employer's environment, but doesn't > seem to here. > > > (General tip when disagreeing with me: I may push back on things -- I > have a reflexive aversion to "you must do it immediately!" when I don't > yet see the need -- but I do try to listen even while dragging my heels. > If you think I'm being foolish or missing something, give me a bit of > time to process the idea, and then calmly bring it up again. Repeat as > necessary.) > > -- > ` /_ Joe Kesselman (he/him/his) > -/ _) My Alexa skill for New Music/New Sounds fans: > / https://www.amazon.com/dp/B09WJ3H657/ > Caveat: Opinionated old geezer with overcompensated writer's block. May > be redundant, verbose, prolix, sesquipedalian, didactic, officious, or > redundant. Feel free to call him on it. >
