bits 0x38 - Calender Week 04, 2024


Do I need a “Rant” section in my weekly post? For this one I’m kinda pissed.

TL;DR it is a human virtue to

  1. clean the commit history before submitting a PR on a collaborated project.
  2. never submit an incomplete series.
  3. prefer rebase over merge

So, someone opened a PR to merge their feature branch into the main. That feature is totally orthogonal to my parts and I’m not reviewing that PR, but it’s trying to introduce the worst VCS practice into main so I have to rant about it.

The commit history in that series looks like this:

| PR 1 | this is a series by the same author, that was merged prior
    +- commit with unclear message
    +- commit with unclear message
    +- commit with unclear message

    PR1 is a partial implementation and NOTHING works.

| PR 2 | this is a series with 20+ commits in it.
    +- commit 1 "add xyz"
    +- commit 2 "Refine code"
    +- commit 3 "Refine code"
    +- commit 4 "Refine code"
    +- commit 5 "revert commit 1"
    +- commit 6 "add abc"
    +- commit 7 "fix bug" (a bug in the same series)
    +- commit 8 "merge branch main into <their own dev branch>"
    +- commit 9 "fix typo"
    +- commit 10 "temp"
    +- .....
    +- mumble mumble
    +- .....

Just imagine having performed every single bad git practice in one single PR. In my opinion this whole series, given what it does, should be no more than 2 commits. Let’s breakdown the rant here.

  • commit 8 is extremely bad compared to others. I guess, while they is working on their dev branch, the main got updated. They merged main into their dev branch to get updated. Perhaps they also fixed some conflicts. In this case: DON’T USE MERGE! Now you are trying to merge the merge back to main, what a mess!
  • commit 2~4 for example, if they serve the same purpose, SQUASH them! this is trivial to do, especially when they are consecutive. And IMO they should not be in this PR in the first place! You are not “refining” any code outside of this series – even if you do, you should point out what code you are refining.
  • commit 10 “temp”, are you kidding me?
  • commit 5 “revert”, again, you are not revert anything outside of this very series, so why even bother putting it in your PR’s commit history?
  • Actually these all boils down to the same problem: not using rebase.
  • Oh I forgot to mention: this PR literally has conflicts with the main.

when it comes to a PR, no one is interested in learning your 心路历程(mental journel) during implementing that feature. It’s about WHAT are the most significant changes, it’s about COMMUNICATION! Please, keep that “shoping list(流水帐)” to yourself and let people understand what’s they are looking at.

If you don’t know how to use rebase, please go through this nice tutorial:

Disclaimer: this rant has nothing to do with code quality, it’s not about how smart the code is, it’s about how you work with people.


the “hygiene” concepts in macros:

It’s about macros being their own syntax context, so that it’s not affected by its surroundings and vice versa.

tilde ~

On Unix-like operating systems (including AIX, BSD, Linux and macOS), tilde normally indicates the current user’s home directory. […] This convention derives from the Lear-Siegler ADM-3A terminal in common use during the 1970s, which happened to have the tilde symbol and the word “Home” (for moving the cursor to the upper left) on the same key.

on Rust optimization: return value optimization (RVO); copy elision

P.S. I posted the findings on fediverse, and, I never expected it to get reposted 200+ times! Of course, who won’t appreciate such a beauty. To my awe some say in the comments that they worked with this specific terminal years back, and some even still have one! That’s a piece of tech way before I was born and :D


Dump a pagetabble, why not?

[+] click to leave a comment [+]
the comment system on this blog works via email. The button
below will generate a mailto: link based on this page's url 
and invoke your email client - please edit the comment there!

[optional] even better, encrypt the email with my public key

- don't modify the subject field
- specify a nickname, otherwise your comment will be shown as   
- your email address will not be disclosed
- you agree that the comment is to be made public.
- to take down a comment, send the request via email.

[BITS] - the weekly archive -
bits 0x53 - Week 28 ~ ?, 2024 (WIP)
bits 0x52 - Week 17~27, 2024 [VOID]
bits 0x51 - Calender Week 17, 2024
bits 0x50 - Calender Week 16, 2024
bits 0x49 - Calender Week 15, 2024
bits 0x48 - Calender Week 14, 2024
bits 0x47 - Calender Week 13, 2024
bits 0x46 - Calender Week 12, 2024
bits 0x45 - Calender Week 11, 2024
bits 0x44 - Calender Week 10, 2024
bits 0x43 - Calender Week 09, 2024 [VOID]
bits 0x42 - Calender Week 08, 2024 [VA]
bits 0x41 - Calender Week 07, 2024 [VOID]
bits 0x40 - Calender Week 06, 2024 [VOID]
bits 0x39 - Calender Week 05, 2024
bits 0x38 - Calender Week 04, 2024
bits 0x37 - Calender Week 03, 2024
bits 0x36 - Calender Week 02, 2024 [VA]
bits 0x35 - Calender Week 01, 2024
bits 0x34 - Calender Week 52, 2023
bits 0x33 - Calender Week 51, 2023
bits 0x32 - Calender Week 50, 2023 [VOID]
bits 0x31 - Calender Week 49, 2023
bits 0x30 - Calender Week 48, 2023
bits 0x2f - Calender Week 47, 2023
bits 0x2e - Calender Week 46, 2023
bits 0x2d - Calender Week 45, 2023
bits 0x2c - Calender Week 44, 2023
bits 0x2b - Calender Week 43, 2023
bits 0x2a - Calender Week 42, 2023