> 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.

I'm not opposed to selective squash in the course of incrementally working on a small detail. But reflexive selection merge-and-squash, or my mistake of thinking I should squash my entire changeset before PR, is probably to be avoided. Merge to no more than a conceptual unit, perhaps.

The issue has been raised that substantially increasing the number of commits increases the number of iterations of git bisect needed to isolate the probable source of an error. Others feel that having more commits increases the precision of bisect's results. There seems to be a tradeoff here. My instinct says that the number of bisects increases logarithmically with number of commits, but frustration may grow exponentially with number of bisect iterations...

My current takeaway is that it may make sense to carefully squash away dead ends and detours and checkpoints on a single concept. But hesitate if inclined to squash more than that.



On 11/18/2023 7:16 PM, Gary Gregory wrote:
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 <mailto: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/
    <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.


--
` /_  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.

Attachment: OpenPGP_0xFFBAFF963D937815.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

Reply via email to