[scrollaway]

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 :)

[finnthehuman]

>The problem with that however is how we use tags today.

"Doctor, it hurts when I cargo-cult workflow from GitHub..."

[abritinthebay]

Hardly. It’s a workflow - that’s all. One that works exceedingly well for millions of people.

[scrollaway]

Do you have a point?

[brlewis]

Point being that one shouldn't cargo-cult workflow from github.

The point is phrased using an old pop culture reference: https://en.wikipedia.org/wiki/Smith_and_Dale#.22Dr._Kronkhei...

[scrollaway]

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.

[jrochkind1]

pushing a tag to github-hosted repo certainly does not automatically create a 'release'.

[stevekemp]

Github "releases" - as listed on the repository index - are solely based on the tags of the repository. So yes, pushing a tag does create a release.

See here for documentation:

https://help.github.com/articles/about-releases/

[jrochkind1]

All releases are tags, not all tags are releases. Have you used the feature?

> 1. On GitHub, navigate to the main page of the repository.

> 2. Under your repository name, click Releases.

> 3. Click Draft a new release.

https://help.github.com/articles/creating-releases/

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).

[bsimpson]

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.

[masklinn]

Been there, done that, it's really not a good idea.

[yes_or_gnome]

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.

  $ git cat-file -p v2.6.13
  object 02b3e4e2d71b6058ec11cc01c72ac651eb3ded2b
  type commit
  tag v2.6.13
  tagger Linus Torvalds <[e-mail]> 1125272548 -0700

  Linux 2.6.13 release
  -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1.4.1 (GNU/Linux)

  iD8DBQBDEkvwF3YsRnbiHLsRAp5tAKCEK1XmOropxvWp+k9eiTcafNMXXACcDAVb
  +hOwdKI+bi84SSNNSGnSXGg=
  =cnNS
  -----END PGP SIGNATURE-----

Edit:

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 <[e-mail]> 1113690036 -0700
  committer Linus Torvalds <[e-mail]> 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!