4 ms·

Torvald's on signing commits : http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-com

Torvald's on signing commits : http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

scrollaway 9y ago
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 9y ago
  >The problem with that however is how we use tags today. "Doctor, it hurts when I cargo-cult workflow from GitHub..."
  - scrollaway 9y ago
    Do you have a point?
    - brlewis 9y ago
      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._Kronkheit_and_His_Only_Living_Patient.22 https://en.wikipedia.org/wiki/Smith_and_Dale#.22Dr._Kronkhei...
      - scrollaway 9y ago
        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.
  - abritinthebay 9y ago
    Hardly. It’s a workflow - that’s all. One that works exceedingly well for millions of people.
- jrochkind1 9y ago
  pushing a tag to github-hosted repo certainly does not automatically create a 'release'.
  - stevekemp 9y ago
    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/ https://help.github.com/articles/about-releases/
    - jrochkind1 9y ago
      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/ 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 9y ago
  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 9y ago
    Been there, done that, it's really not a good idea.
- yes_or_gnome 9y ago
  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 <torvalds@g5.osdl.org> 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 <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!
rvern 9y ago
Mike Gerwitz on signing commits: https://mikegerwitz.com/papers/git-horror-story https://mikegerwitz.com/papers/git-horror-story.

Torvald's on signing commits : http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

scrollaway 9y ago

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 9y ago
>The problem with that however is how we use tags today. "Doctor, it hurts when I cargo-cult workflow from GitHub..."
- scrollaway 9y ago
  Do you have a point?
  - brlewis 9y ago
    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._Kronkheit_and_His_Only_Living_Patient.22 https://en.wikipedia.org/wiki/Smith_and_Dale#.22Dr._Kronkhei...
    - scrollaway 9y ago
      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.
- abritinthebay 9y ago
  Hardly. It’s a workflow - that’s all. One that works exceedingly well for millions of people.
jrochkind1 9y ago
pushing a tag to github-hosted repo certainly does not automatically create a 'release'.
- stevekemp 9y ago
  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/ https://help.github.com/articles/about-releases/
  - jrochkind1 9y ago
    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/ 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 9y ago
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 9y ago
  Been there, done that, it's really not a good idea.
yes_or_gnome 9y ago
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 <torvalds@g5.osdl.org> 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 <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!

rvern 9y ago

Mike Gerwitz on signing commits: https://mikegerwitz.com/papers/git-horror-story https://mikegerwitz.com/papers/git-horror-story.