Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
What are the benefits of starting a Git repo with an empty commit?
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.
git logand other commands blow up with terrifying error messages.2. You can’t
git resetback to that initial state.Based on the first 2 section titles above I suspected that this may be a satirical writing.
-
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).
-
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.
-
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:
Both have the main theme of "How to rebase the whole history, including the first commit?".
2 answers
This sounds to me like someone had a problem once and they've decided upon a somewhat silly way to keep that from ever happening again.
The big repository hosts have a different way of addressing it. They (offer to) make you a README.md and a .gitignore for the first commit and you can stem everything from that.
- You can’t
git resetback to that initial state.
If you really want to reset back to literally nothing, just start a new repository.
- You can’t rebase the initial commit.
The author asserts point 3, but then they immediately show the command you can use to do it:
git rebase --interactive --root
0 comment threads
Quoting an answer from SO:
Perhaps there was an advantage years ago prior to version 1.17.12 which added the
--rootoption 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:
- 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.
- 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.
The linked answer is licensed under CC BY-SA 4.0 and it was quoted verbatim as it was on 11/8/2023 at 1013.
Git version 1.7.12, which added --root, was released in 2012.
0 comment threads
0 comment threads