lkml.org 
[lkml]   [2011]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [git patches] libata updates, GPG signed (but see admin notes)
    Date
    Linus Torvalds <torvalds@linux-foundation.org> writes:

    > Having thought about it, I'm also not convinced I really want to
    > pollute the "git log" output with information that realistically
    > almost nobody cares about. The primary use is just for the person who
    > pulls things to verify it, after that the information is largely stale
    > and almost certain to never be interesting to anybody ever again. It's
    > *theoretically* useful if somebody wants to go back and re-verify, but
    > at the same time that really isn't expected to be the common case.
    > ...
    > So I'm wondering if we want to save it at all. it's quite possible
    > that realistically speaking "google the mailing list archives" is the
    > *right* way to look up the signature if it is ever needed later.

    I'd rather want to hear opinions from people who base their work on public
    kernels (e.g. distros, and companies who roll their own prod kernels), on
    that.

    But my gut feeling is that "usually hidden not to disturb normal users,
    but is cast in stone in the history and cannot be lost" strikes the right
    balance. Both your "next merge commit records the signature together with
    the largely useless merge summary cruft but everybody learned to ignore it
    with 'log --no-merges' anyway so it does not hurt to have it there" and
    the commit signature topic from the next branch [*1*] that puts the
    signature in the object header and teaches '--show-signature' option to
    the log family to show it share this property.

    > Maybe just verifying the email message (with the suggested kind of
    > change to "git request-pull") is actually the right approach. And what
    > I should do is to just wrap my "git pull" in some script that I can
    > just cut-and-paste the gpg-signed thing into, and which just does the
    > "gpg --verify" on it, and then does the "git pull" after that.
    >
    > Because in many ways, "git request-pull" is when you do want to sign
    > stuff. A developer might well want to push out his stuff for some
    > random internal testing (linux-next, for example), and then only later
    > decide "Ok, it was all good, now I want to make it 'official' and ask
    > Linus to pull it", and sign it at *that* time, rather than when
    > actually pushing it out.
    >
    > And I suspect signing the pull request fits better into peoples
    > existing workflow anyway - sending out the email to ask the maintainer
    > to pull really is the "special event", rather than pushing out the
    > code itself.

    "I can silently push and re-push or even rewind-and-then-push until I
    officially send pull-request out" fits well with the "defer the decision
    as much as possible" model Git takes in general, and I find certain
    attractiveness in it.

    But on the other hand, in many ways, publishing your commit to the outside
    world, not necessarily for getting pulled into the final destination
    (i.e. your tree) but merely for other people to try it out, is the point
    of no return (aka "don't rewind or rebase once you publish"). "pushing
    out" might be less special than "please pull", but it still is special.

    Also there is nothing lost if you sign commits whenever you push them
    out.


    [Footnote]

    *1* Here are three examples on the same commit that is signed for
    illustration.

    ------------------------------------------------
    $ git show -s pu
    commit c9d870fceac787fdb1c1c43b136c1a94ab2ab005
    Merge: 8367c51 71f45ee
    Author: Junio C Hamano <gitster@pobox.com>
    Date: Mon Oct 31 20:06:58 2011 -0700

    Merge branch 'jc/stream-to-pack' into pu

    * jc/stream-to-pack:
    Bulk check-in
    finish_tmp_packfile(): a helper function
    create_tmp_packfile(): a helper function
    write_pack_header(): a helper function
    ------------------------------------------------
    $ git show -s --show-signature pu
    commit c9d870fceac787fdb1c1c43b136c1a94ab2ab005
    gpg: Signature made Mon 31 Oct 2011 08:07:04 PM PDT using RSA key ID 96AFE6CB
    gpg: Good signature from "Junio C Hamano <gitster@pobox.com>"
    gpg: aka "Junio C Hamano <junio@pobox.com>"
    gpg: aka "Junio C Hamano <jch@google.com>"
    Merge: 8367c51 71f45ee
    Author: Junio C Hamano <gitster@pobox.com>
    Date: Mon Oct 31 20:06:58 2011 -0700

    Merge branch 'jc/stream-to-pack' into pu

    * jc/stream-to-pack:
    Bulk check-in
    finish_tmp_packfile(): a helper function
    create_tmp_packfile(): a helper function
    write_pack_header(): a helper function
    ------------------------------------------------
    $ git cat-file commit pu
    tree 9add290d468800c3c51ff68fedfb3d16427872ff
    parent 8367c51becc5a225b9a192348b7d7c615fb6d250
    parent 71f45eeb8278670257bea83620f7d3eac174eee7
    author Junio C Hamano <gitster@pobox.com> 1320116818 -0700
    committer Junio C Hamano <gitster@pobox.com> 1320116824 -0700
    gpgsig -----BEGIN PGP SIGNATURE-----
    gpgsig Version: GnuPG v1.4.10 (GNU/Linux)
    gpgsig
    gpgsig ...
    gpgsig =c62U
    gpgsig -----END PGP SIGNATURE-----

    Merge branch 'jc/stream-to-pack' into pu

    * jc/stream-to-pack:
    Bulk check-in
    finish_tmp_packfile(): a helper function
    create_tmp_packfile(): a helper function
    write_pack_header(): a helper function
    ------------------------------------------------



    \
     
     \ /
      Last update: 2011-11-01 22:59    [W:0.028 / U:0.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site