git-cliff can generate changelog files from the Git history by utilizing conventional commits as well as regex-powered custom parsers. The changelog template can be customized with a configuration file to match the desired format.

Very cool Marcus, very cool!

…let’s say that my code lives in $HOME/work and my personal code lives in $HOME/projects. You can do something like this

[user]
  email = user@example.com
  name = User
  signingkey = ABC123
[commit]
  gpgSign = true
[includeIf "gitdir:~/work/"]
  path = ~/.work.gitconfig

This week, Richard Hipp returns to catch us up on all things SQLite, his single file webserver written in C called Althttpd, and Fossil – the source code manager he wrote and uses to manage SQLite development instead of Git.

in version 2.23 of git, two new commands have been introduced to replace the old git checkout (git checkout is still available, but people new to git should start with these ones preferably). As you would expect, they basically each implement one of the two behaviors described previously, splitting git checkout in two.

TIL!

HOW HAVE I NOT HEARD OF GIT WORK TREES??? WHAT THE EFF. They are so incredible. You have to check them out!!! In this video I go over them briefly, assuming you are smart enough to understand them, and also show you my workflow with vim! Its fantastic!

Commit groups sounds interesting to me. Anyone reading this familiar with Git innards? Is this doable?

You know the “group” facility of vector graphics programs? You draw a couple of shapes, you group them together, and then you can apply transformations to the entire group at once, operating on it as if it were an atomic thing. But when need arises, you can “ungroup” it and look deeper.

I’d love to see that same idea applied to Git commits. In Git, a commit group might just be a named and annotated range of commits: feature-a might be the same as 5d64b71..3db02d3. Every Git command that currently accepts commit ranges could accept group names. I envision groups to have descriptions, so that git log, git blame, etc could take –grouped or –ungrouped options and act appropriately.

Sad but true: Git is simply too hard. One thing driving said truth is that undoing things often requires jumping through obscure hoops. Here’s what Waleed Khan has to say on the matter:

Well, it’s not that it’s too easy to lose your data — but rather, that it’s too difficult to recover it. For each operation you want to recover from, there’s a different “magic” incantation to undo it. All the data is still there in principle, but it’s not accessible to many in practice.

Here’s my theory: novice and intermediate users would significantly improve their understanding and efficacy with Git if they weren’t afraid of making mistakes.

To address this, Waleed created git undo as part of his git-branchless suite of tools.

LJ Miranda:

When I first saw “Avengers: Endgame” in theaters, I noticed that their time travel rule is quite similar to the Git branching model. Referred to as the time heist, our heroes travelled through time to recover the stones…

I had to truncate that pull quote to avoid Avengers spoilers. If you’ve seen the movie (or don’t care about getting spoiled) there’s some good Git knowledge to be gained from this analogy.

Chris Manson goes into detail about the benefits of a clean git history and describes some tips and tricks that really help you clean up your branches and Pull Requests.

Any git repository may contain tons of information about commits, contributors, and files. Extracting this information is not always trivial, mostly because there are a gadzillion options to a gadzillion git commands – I don’t think there is a single person alive who knows them all. Probably not even Linus Torvalds himself :).

A handy shell script to help you undo all the things (commits, pushes, pulls, you name it).

Here is an example to help you understand the importance of cherry-picking. Suppose you have made several commits in a branch, but you realize it’s the wrong branch! What do you do now? Either you repeat all your changes in the correct branch and make a fresh commit, or you merge the branch into the correct branch. Wait, the former is too tedious, and you may not want to do the latter. So, is there a way? Yes, Git’s got you covered.

I’m a pretty big fan of cherry-pick, too. I don’t use it often, but every time I do… 👨‍🍳💋

Imagine a world where Git and MySQL got together and had a baby. They would name that baby, Dolt.

Dolt is a SQL database that you can fork, clone, branch, merge, push and pull just like a git repository. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files, commit your changes, push them to a remote, or merge your teammate’s changes.

All the commands you know for Git work exactly the same for Dolt. Git versions files, Dolt versions tables.

The authors also created DoltHub where you can host and share your Dolt databases.

Sometimes you need to communicate changes to other developers on your project. In a small team, a Slack message works okay, but in larger teams and distributed organizations (such as open source projects), reaching everyone can be a pain.

Logging this because it’s an interesting idea, but I’m not sure if it’s a good idea. Is this a good idea?

Martin Heinz shares some of his favorite git features: word diff, auto-correct, plugins, and commit signing.

Git is the perfect technology to maximize cheat sheet value. It has a large surface area of commands and requires some esoteric combos to get things done. (Why is there still not a git undo?)

Jonas Lundberg:

We all do it. Up to many times a day and yet it’s rare that I meet someone that has given it a second thought. No, it’s not secretly snacking chocolate from your top office drawer.

It’s how you write and structure your commits. Possibly while snacking chocolate.

What follows is a piece marrying atomic commits (as in small commits with one focus) with Donald Knuth’s literate programming. It ends with some research on whether or not this practice commonplace on the 100 most popular GitHub repos.

Remember Patrick DeVivo’s super cool AskGit project where you can query your git repo’s history with SQL? Well, now you can kick the tires without installing a thing by using AskGit’s new web interface!

Here’s an example query where we learn that I do most of my coding (or committing, at least) on Mondays and Tuesdays while Adam and Gerhard lean towards Friday.

It was covered in fantastic detail on the Changelog #414 but now it’s real. Gitter now works natively with Matrix.

In which I detail A SQL query that helps you identify files in a codebase that have “churned” in the past year. In other words, list the files that have been changed by the most number of commits in the last year.

SELECT file,
       COUNT(*)
FROM   stats
       JOIN commits
         ON stats.commit_id = commits.id
WHERE  commits.author_when > DATE('now', '-12 month')
       AND commits.parent_count < 2 -- ignore merge commits
GROUP  BY file
ORDER  BY COUNT(*) DESC
LIMIT  50

Git is actually sooo hard. Not just to learn, but also to use consistently. And I say that as a person who used it for probably over ten years. Here’s my thoughts on the matter.

Daniel Stenberg:

Every now and then I get questions on how to work with git in a smooth way when developing, bug-fixing or extending curl – or how I do it. After all, I work on open source full time which means I have very frequent interactions with git (and GitHub). Simply put, I work with git all day long. Ordinary days, I issue git commands several hundred times.

I have a very simple approach and way of working with git in curl. This is how it works.

A nice, visual way of learning the most common git commands and how they do what they do.

bit is an experimental modernized git CLI built on top of git that provides happy defaults.

This is not a tutorial on using Git! To follow along I advise that you have working knowledge of Git. If you’re a newcomer to Git, this tutorial is probably not the best place to start your Git journey. I suggest coming back here after you’ve used Git a bit and you’re comfortable with making commits, branching, merging, pushing and pulling.