[lkml]   [2011]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [git patches] libata updates, GPG signed (but see admin notes)
    Linus Torvalds <> writes:

    > But what would be nice is that "git pull" would fetch the tag (based on
    > name) *automatically*, and not actually create a tag in my repository at
    > all. Instead, if would use the tag to check the signature, and - if we
    > do this right - also use the tag contents to populate the merge commit
    > message.
    > In other words, no actual tag would ever be left around as a turd, it
    > would simply be used as an automatic communication channel between the
    > "git push -s" of the submitter and my subsequent "git pull". Neither
    > side would have to do anything special, and the tag would never show
    > up in any relevant tree (it could even be in a totally separate
    > namespace like "refs/pullmarker/<branchname>" or something).

    While I like the "an ephemeral tag is used only for hop-to-hop
    communication to carry information to be recorded in the resulting
    history" approach, I see a few downsides.

    * The ephemeral tag needs to stay somewhere under refs/ hierarchy of the
    lieutenant's tree until you pick it up, even if they are out of the way
    in refs/pullmarker/$branchname. The next time the same lieutenant makes
    a pull request, either it will be overwritten or multiple versions of
    them refs/pullmarker/$branchname/$serial need to be kept.

    - If the former, this makes forking of the project harder. Suppose a
    pull request is made, you fetch and reject it. The lieutenant reworks
    and makes another pull request. At this point the earlier signature
    is gone. If somebody disagreed with your rejection and wanted to run
    his tree with the initial version you rejected, his tree will not
    carry the signature from the lieutenant.

    - If the latter, then there needs to be a way to expire these pull
    markers when they no longer are useful (i.e. the signature in it is
    transcribed to a merge commit you create) [*1*]. But the party who
    has power to clean them (i.e. the lieutenant who owns the repository)
    is different from the party whose action determines when they no
    longer are necessary (i.e. you). In practice this would lead to these
    pull markers not cleaned at all [*2*].

    * To verify the commit C that was taken from the tip of lieutenant's tree
    some time ago, one has to find the merge commit that has C as a parent,
    and look at the merge commit. For example "git log --show-signature"
    would either show or not show the authenticity of C depending on where
    the traversal comes from. You certainly can implement it that way, but
    "some child describes an aspect of its parent, but not necessarily all
    children do so" feels philosophically less correct than "the commit has
    data to describe itself".

    In your "ephemeral tag", the workflow for a developer (D) and his
    integrator (U) would look like this, I think.

    D$ until have something worth sending; do work; done
    D$ git push -s
    Enter passphrase: ...
    - "push" internally creates a pull marker that signs the commit
    object name this is pushing, among other things, and sends it
    along the primary payload
    D$ git pull-request; mail linus

    U$ git pull
    - "pull" notices the pull marker and fetches it as well;
    - "pull" GPG validates the pull marker;
    - When preparing a merge commit message, the contents of the
    pull marker is included in .git/MERGE_MSG

    The "in-commit signature" would give you 100% and your contributors 98% of
    that, I think.

    D$ until have something worth sending; do work; done
    - The final round of reworking is concluded with "commit -S",
    which would GPG sign the tip commit itself
    D$ git push
    - Nothing needs to change in the protocol nor "push" itself
    D$ git pull-request; mail linus

    U$ git pull
    - "pull" GPG validates the tip commit
    - Nothing unusual needs to happen to the resulting "merge" commit

    And as a bonus, the code is already there ;-).


    *1* The common ancestor discovery in fetch uses as many refs as it can to
    reduce the amount of data that needs to be transferred, and it is known to
    hurt performance of the initial advertisement exchange when there are too
    many useless refs.

    *2* Do casual git users even know how to remove refs in a
    remote/publishing repository?

     \ /
      Last update: 2011-11-01 20:49    [W:0.024 / U:1.676 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site