The problem is that what I want is for "git init --nil" to do that, not for some "git nilinit".
Actually, I want "git init" to do that by default!
Every git repo should begin with an empty commit.
In fact, there should be a special SHA built in representing the empty commit; perhaps an all-zero SHA. This object is understood not to occupy any space in the object store beyond its own SHA: you don't look for an all zero SHA in the object space; it just stands for itself.
Then this same can be used as a parent in any orphan branch.
One of the benefits is that this zero SHA is global. And so all git repos have a common ancestor automatically.
If you and I take some code tarball (the same one) and start git repos individually, then we implicitly have a common merge-base: the NIL commit. If I pull from your repo, then we have this:
your-import and my-import are the same since we imported the same thing. I can just do a "git rebase your-hacks-branch" to transplant my-hacks over your-hacks, implicitly using NIL as the merge-base.
Actually, I want "git init" to do that by default!
Every git repo should begin with an empty commit.
In fact, there should be a special SHA built in representing the empty commit; perhaps an all-zero SHA. This object is understood not to occupy any space in the object store beyond its own SHA: you don't look for an all zero SHA in the object space; it just stands for itself.
Then this same can be used as a parent in any orphan branch.
One of the benefits is that this zero SHA is global. And so all git repos have a common ancestor automatically.
If you and I take some code tarball (the same one) and start git repos individually, then we implicitly have a common merge-base: the NIL commit. If I pull from your repo, then we have this:
your-import and my-import are the same since we imported the same thing. I can just do a "git rebase your-hacks-branch" to transplant my-hacks over your-hacks, implicitly using NIL as the merge-base.