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:))

  • FiniteLooper@lemm.ee
    link
    fedilink
    English
    arrow-up
    17
    ·
    8 months ago

    I made a branch, make commits, and then make a PR. I don’t care about the number of commits because sometimes a reviewer might be able to make more sense of a PR if they view each commit instead of all the changes at once.

    For us we just make sure that the branch builds and passes tests before merging it in, and just do a general look over to make sure everything looks correct, follows best practices, etc. if the UI was changed I usually add screenshots of before/after or a screen recording of me using the feature. Sometimes these can really help a reviewer understand what all the changes mean.

    • bamboo@lemmy.blahaj.zone
      link
      fedilink
      English
      arrow-up
      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.zone
          link
          fedilink
          English
          arrow-up
          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.