For non-trivial reviews, when there are files with several changes, I tend to do the following in Git:

  1. Create local branch for the pr to review
  2. Squash if necessary to get everything in the one commit
  3. Soft reset, so all the changes are modifications in the working tree
  4. Go thru the modificiations “in situ” so to speak, so I get the entire context, with changes marked in the IDE, instead of just a few lines on either side.

Just curious if this is “a bit weird”, or something others do as well?

(ed: as others mentioned, a squash-merge and reset, or reset back without squashing, is the same, so step 2 isn’t necessary:))

  • bamboo@lemmy.blahaj.zoneEnglish
    8·
    8 months ago

    In my experience, I prefer to review or contribute commits which are logical changes that are compartmentalized enough that if needed, they could be reverted without impacting something completely differently. This doesn’t mean 1 commit is always the right number of commits in a PR.

    For example, if you have a feature addition which requires you to update the version of a dependency in the project, and this dependency update breaks existing code, I would have two commits, being:

    • Update dependency and fix issues because of the upgrade
    • Add new feature using new dependency

    When stepping through the commits in the PR or looking at a git blame, it’s clear which changes were needed because of the new dependency, and which were feature additions.

    Obviously this isn’t a one size fits all, but if someone submitted a PR with 12 commits of trial and error, and the overall changes are like +2 lines -3 lines, I’d ask them to clean that up before it gets merged.

      • bamboo@lemmy.blahaj.zoneEnglish
        3·
        8 months ago

        Right, for junior devs or trivial changes, that’s fine. My take is if I’m going to make someone take the time to review my work, I take the time to make sure that it’s cleaned up and would be something I would merge if I were reviewing it. Most of this comes from working on some larger Open Source projects which still require patches be submitted via email which I know is a real “back in my day” moment, but it did instil good practices which I try to carry on.