4 ms·
Eh, just make an alias in ~/.gitconfig no need to add more options to git. That is: [alias] nilinit = !sh -c 'git init && git commit --allow-empty -
by mitchty 12y ago
Eh, just make an alias in ~/.gitconfig no need to add more options to git.
That is:
[alias]
nilinit = !sh -c 'git init && git commit --allow-empty -m NIL'
And now git nilinit does what you want.
- kazinator 12y agoThe 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 <--- your-hacks / NIL \ my-import <--- my-hacks 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.
- mitchty 12y agogit-subtree already allows for embedding one git repo in another. https://github.com/git/git/blob/master/contrib/subtree/git-subtree.txt https://github.com/git/git/blob/master/contrib/subtree/git-s... I see the point but not sure I agree that we should treat all git repositories as having a common base commit. Not thought it through however.