Why empty commits are good

Empty commits

I once read an https://bit-booster.com/doing-git-wrong/2017/01/02/git-init-empty/ , about why 
you should start with an empty commit for a new repo. The page has since then dissapperard but I got 
some of it out of the wayback machine and archive it here:

Always Start With An Empty Commit
Whenever you start a new git repo, pop an empty commit onto it before you do anything else!

git init new-repo
cd new-repo
git commit -m 'initial empty commit' --allow-empty
git tag init

1. “git log” and other commands blow up with terrifying error messages.
This was true a couple years ago:

$ git --version
git version 2.5.1

$ git log
fatal: bad default revision 'HEAD'
But things have gotten better as of git version 2.5.2:

$ git --version
git version 2.5.2

$ git log
fatal: your current branch 'master' does not have
any commits yet
I tried switching my computer to Korean to see if that makes a difference:

$ git log
fatal: 현재 'master' 브랜치에 아직 아무 커밋도 없습니다
I cannot read or understand Korean, but seeing ‘master’ in there suggests that even in Korean the message is now less terrifying.

2. You can’t “git reset” back to that initial state.
Stackoveflow doesn’t appear to know this trick yet, but you can do this from your repository’s root directory:

git checkout --orphan primordial_nothingness
git rm -rf .
git commit --allow-empty -m 'floating empty void'
git push origin refs/heads/primordial_nothingness
Run the commands above (once per repo), and from then on the void is just a quick 46 keystrokes away: 
“git reset –hard origin/primordial_ nothingness”. Unless of course some jerk goes and commits against your 
primordial_nothingness branch. But if that ever happens, you know how to get the void back! Run the same steps above, 
but end with a force-push.

3. You can’t rebase the initial commit.

“I think we’re gonna be stuck with this commit forever.  I can’t seem to rebase it.”
If you are profoundly unhappy with your first few commits, you could just refuse to push them.  Sweep them under the rug 
via “rm -rf .git” and never tell a soul.  Here’s an example:

$ git log --oneline
261e747 c
39b91e3 b
212a17d a
Not happy with those initial three commits above? Blast away the “.git” directory, re-init, recommit:

$ rm -rf .git
$ git init
$ git add .
$ git commit -m 'a b c'

$ git log --oneline
d3b7ca4 a b c
Et voilà, the commit exactly as you dreamed it.  Sure, it’s a little bit of typing, but it uses vanilla git commands that 
any beginner should know.  The only trick is deleting the “.git/” directory.

Now, if the current date is after July 25th, 2012, then there is another way.  You can take advantage of git’s very own 
commit “7b9f29c4”:

commit 7b9f29c40f52084c4e3abf7d2a4212c15aa63ae6
Merge: b00445bc3 2147f844e
Author: Junio C Hamano <[email protected]>
Date:   Wed Jul 25 15:46:59 2012 -0700

    Merge branch 'cw/rebase-i-root'
    
    Finishing touches to the "rebase -i --root"
    (new feature for 1.7.12).
    
    * cw/rebase-i-root:
      rebase -i: handle fixup of root commit correctly
The trick here is to remember to use “–root” instead of “HEAD~N” or “@{u}” or however it is you typically reference the 
commit you’re rebasing to.  So instead of this:

git rebase --interactive HEAD~3
Or instead of this:

git rebase --interactive @{u}
Try this!

git rebase --interactive --root

This is such a gem