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

  • @[email protected]
    link
    fedilink
    0
    edit-2
    8 months ago

    K what do I know, it’s just what I’ve done on code bases with ~5 million lines of code, at the point where no one understands even half of it.

    • @pixxelkick
      link
      08 months ago

      Everything about what you just wrote, and the way you represented it, signals you are precisely the type of individual that should take everything about what I wrote above very much to heart, friend.

      If you have no idea what I’m talking about, I hope one day you do :)

        • @pixxelkick
          link
          0
          edit-2
          8 months ago

          There’s not really a nice way to frame “your post sounds like it was written by an extremely cringe teenager trying to cosplay as their idea of what constitutes a professional dev, demonstrated by the classic combination of ignoring everything prior written, attempting to represent a ball of mud as a badge of honor, and unironically trying to use lines of code count as a metric to measure by”

          Literally checked off all the “lol sure bud” boxes in a single statement, and then if you aren’t picking up on the nuance, let me explain what I wrote after:

          I hope you understand later how incredibly cringe what you wrote is, because the day you do is the day you have likely matured enough in knowledge and skill to call yourself a professional unironically, which is a good thing.

          Until that day, stop prostrating shit like what you just wrote above if you ever want any developer worth their salt to take you even remotely seriously, otherwise you will likely find yourself the laughing stock very quickly of any serious circle.

          Best of luck out there, and finally:

          Next time someone is giving extremely useful advice, just write it down, don’t shit talk. That’s without a doubt the #1 divergence that separates the path between long term failure vs success.