Jujutsu is indeed alluring... but its long term support is questionable, that's what keeps me away from it for now.

Looks like a nice way to improve handling of merge conflicts. I'll test this one out.

Ooh! This looks like a really neat improvement. I wonder how reliable this is, I'll definitely test it.

A bit too much of a rant for my taste (even though I agree with the GitHub flaws). That said it illustrates nicely a use of git range-diff which is often overlooked.

Maybe we could store metrics about the code in the history as well? This would indeed reduce vendor lock-in. This tool makes it easy. Unsurprisingly seems built upon git notes.

I like the idea of getting all the review comments back into Git once things are merged. This works offline, makes you less dependent on the forge for historical data etc. Now we'd probably need to have the notes feature easier to use somehow.

Oh fancy! I didn't know this git log parameter. Definitely useful.

A nice collection of versioning schemes. I definitely didn't know them all.

The often forgotten history behind the creation of Git. This article does a good job summarizing it.

Very extensive guide on writing better commit messages. This is important, it's a very central communication mechanism with other developers.

Or why a clean commit history can help quite a lot to find how and why a bug was introduced. This shows a few nice tricks around git log to speed up the process.

Good explanations on how HEAD works in git and what it means. It's indeed one of those terms where the consistency isn't great in git.

Looks like an interesting approach for a new family of development forges. Fully distributed and peer to peer, I wonder if it'll pick up.

Good reminder that git worktrees exist. They definitely come in handy sometimes.

Going back on the history of the introduction of version control in software engineering and how Git ended up so dominant. We often forget there was a time before Git.

Nice list of tips and recent git features to manage large repositories.

Indeed the example is a bit extreme. Still it illustrate quite well what should be found in a commit message. It needs to tell a story and motivate the reasons behind a change.

A nice knowledge base about what is probably my favorite branching model. Goes in the variations you can have, the trade-offs and the other techniques you need to bring in for it to work well.

So, which team are you on when you think about commits in Git?

It looks like git workflows using rebase are becoming the norm. People are actively trying to avoid merge commits in their repository history. Tooling support could be a bit better though.