What are the benefits of starting a Git repo with an empty commit?

Question

Found an article about starting a repo with an empty commit. Read the post a couple of times, but still don't understand the reasoning:

1. 1. git log and other commands blow up with terrifying error messages.

   2. You can’t git reset back to that initial state.

   Based on the first 2 section titles above I suspected that this may be a satirical writing.

2. 3. You can’t rebase the initial commit.

   This however seems like a valid point (echoed by a linked article, Lesser Known Git Commands, found in the original post), but when I start thinking about it, I just can't see how this is useful in practice (or what it tries to prevent).

3. Linked in the original post: (2008?) Git Magic - Appendix A. Git Shortcomings: Initial Commit

   I agree with the "counting from 0" sentiment, but still don't get what would be the benefits of an empty initial commit, other than being pedantic.

4. Linked in the original post: (2010) How I initialize my Git repositories | Kevin Deldycke

   This post does give a rationale for using this trick for code archeology purposes (still don't get the specifics, but I understand that this is for a special use case).

Links in items 3. and 4. are obviously dated and this whole idea obviously never took off(?), but I'm still wondering if there is still a benefit to it - or the changes in Git since then obviate its necessity.

---

Of course, after typing all this did I find the SO threads:

• Insert a commit before the root commit in Git?
• How do I git rebase the first commit?

Both have the main theme of "How to rebase the whole history, including the first commit?".

Answer 1

Perhaps there was an advantage years ago prior to version 1.17.12 which added the --root option to rebase. Nowadays though, I can't think of any reason to start with an empty commit for a new repository.

However, there may still be some minor advantages when re-organizing existing repositories, for example:

1. When combining existing repositories into a monorepo, you could start with one repo and merge in the others, or you could start with an empty commit and merge in each repo to that commit, so the first-parent history is preserved from the point of view of the new monorepo instead of one of the existing repos. It also allows you to provide additional information in the merge commit for bringing in that first repo.
2. When porting source code from SCMs other than Git, some tools may expect a Git anchor commit to work against, so that the loop can be identical for every new commit, rather than having different logic for the initial commit.