I create an empty root commit whenever I start a new git repository to allow me to rebase up to the first actual change. I almost never have to do that, but it’s great to have if I do.
$ git commit --allow-empty -m "$ git init"
@citizen428 That’s right! However, updating the root commit using that approach removes the common ancestor from already-created branches, which makes them more difficult to merge.
The empty root is there to always be the common ancestor.
@jkreeftmeijer We clearly use different branching strategies, I can't come up with a single instance where this would have been a problem in 10+ years of using git. :-)
@citizen428 I’ve had projects where I had to update the initial commit after already branching out, especially when I build descriptive example projects with descriptions in their commit messages, like this one (https://github.com/jeffkreeftmeijer/hayago), for example.
If you’re fine with adding another commit, that’s not an issue. However, that wasn’t really an option in this case, because that would break the step-by-step descriptions.
@jkreeftmeijer Totally legit use case, I probably should have said "branching needs", not "branching strategies".
Server run by the main developers of the project 
It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!
@jkreeftmeijer There’s a —root option for rebase that let’s you do this without needing an empty commit.