He makes excellent points on tags; the one I hadn't considered before is that tags indeed can be separated from the tree, which makes them a unique asset in a git tree.
The problem with that however is how we use tags today. Creating a tag in the modern lingua franca of git means creating a new version. If you push that tag to Github or Gitlab or what have you, a handy "release" will be created for you. If you're signing all your commits for some security reason, you don't want that, aye?
So you'd want tags that are tracked separately and that's not easy to do. `git commit --sign` is going to include the signature in the commit, not create a separately-tracked tag with an appropriate name or whatever. It certainly sounds interesting, albeit unintuitive, and that summarizes git perfectly :)
It's not cargo-culting, it's not from github, and it's not even a workflow. If that was the point, it's a terrible one to make. I genuinely don't understand how people found that comment insightful, or anything short of trolling/hostile, but whatever.
Pushing a tag does not create a release. You can have lots of tags that are not releases. You have to choose to create a release, as a separate step. All your releases are tagged though, yes (as they should be, using github and it's release feature or not, to identify the state of the repo from which the release was built).
Tags are also how the code review tool Phabricator sends diffs to CircleCI for testing. If you have that integration enabled, you quickly end up with more GitHub Releases than your project has commits.
Based on my own research, it appears that the first git tag was created before the first git commit.
The first tag (?) points to a tree.
$ git cat-file -p v2.6.11-tree
object c39ae07f393806ccf406ef966e9a15afc43cc36a
type tree
tag v2.6.11-tree
This is the 2.6.11 tree object.
NOTE! There's no commit for this, since it happened before I started with git.
Eventually we'll import some sort of history, and that should tie this tree
object up to a real commit. In the meantime, this acts as an anchor point for
doing diffs etc under git.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCeV/eF3YsRnbiHLsRAl+SAKCVp8lVXwpUhMEvy8N5jVBd16UCmACeOtP6
KLMHist5yj0sw1E4hDTyQa0=
=/bIK
-----END PGP SIGNATURE-----
First commit
$ git cat-file -p v2.6.12-rc2
object 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
type commit
tag v2.6.12-rc2
Linux v2.6.12-rc2 release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQBCbW8ZF3YsRnbiHLsRAgFRAKCq/TkuDaEombFABkPqYgGCgWN2lQCcC0qc
wznDbFU45A54dZC8RZ5JxyE=
=ESRP
-----END PGP SIGNATURE-----
Unfortunately, I don't think I can confirm my suspicion using git alone. Maybe if I look at some mailing lists around July/August 2005 I could get a more accurate confirmation.
This is due to the fact that those tags pre-date the tagger header which came a short while later.
Just to reenforce the "First Commit" claim, here's the rev-list for the commit and the commit contents. (Notice it has no "parent" commit.
$ git rev-list 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
$ git dump 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
tree 0bba044c4ce775e45a88a51686b5d9f90697ea9d
author Linus Torvalds <torvalds@ppc970.osdl.org> 1113690036 -0700
committer Linus Torvalds <torvalds@ppc970.osdl.org> 1113690036 -0700
Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.
Let it rip!
