I see this so often, but I don't understand it. Some people just fork a huge amount of repos and never commit anything to them. What's the point? Are they trying to pad their profile for potential employers or what?

It just clutters your active repos. Personally, I just remove forks once my PR gets merged upstream. And I only fork when I'm ready to push a commit.

Is there something I'm missing?

Back in 2016 I finally moved from mercurial to a git-based tool for version controlling my home dir. I now have six repos. The link is to my first article on it. I use tagging on my blog so you can find the other vcsh articles from there. It makes switching machines super-simple and encourages me to write utilities to make my life easier.

Also, very nice-looking website

With git/github I really only pull and push. I don't really use any of the other features. Same for the kids on my robotics team. The only thing I have taught them is pull and push. The kids do a pull at the beginning of practice and a push at the end. Yet sometimes I see this in the commit logs. Why are these merges happening? Even I have some merges and I know I didn't do anything differently. Should I be concerned? We are doing all of our git/gihub work in VS code if that matters.

Over the last year I've been trying to understand why GPG isn't popular. Based on the features I think it's a pretty valid thing. This article changed my mind.

Turns out GPG is too old ¯_(ツ)_/¯

I like signing my commits, it feels good to know that my identity is actually attached to my code. So I put in some work to reconfigure git to use a different signing tool, I didn't think it would be such a big deal, turns out git fully intergrates GPG. I'm confused. Why does git need to be hardcoded to use GPG specifically?

What rule says we can't have git configs like:

[sigining]
  defaultMethod=minisign

[signing.minisign]
  always=true
  signCommand=minisign -S -s {secret-key-file} -x {sig-file-name} -m {target-file}
  verifyCommand=minisign -V -P {public-key-file} -m {target-file}

Where the verifyCommand exits 0 if the signature is good and 1 if not.

I'm open to hearing cons. These are some I can think of:

• User's have to configure git with each signing and verifying program
• Upstream security conserns from signing programs
• Signing programs changing their interfaces

With Github so popular now, not everyone is aware of the workflows that git provides out-of-the-box for collaboration. Thought this may pique some people's curiosity :)