[lkml]   [2011]   [Nov]   [9]   [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:

    > No, no, don't consider my "put in the merge message" a winner at all.
    > I personally dislike it, and don't really think it's a wonderful thing
    > at all. I really does have real downsides:
    > - internal signatures really *are* a disaster for maintenance. You
    > can never fix them if they need fixing (and "need fixing" may well be
    > "you want to re-sign things after a repository format change")
    > - they are ugly as heck, and you really don't want to see them in
    > 99.999% of all cases.
    > So putting those things iin the merge commit message may have some
    > upsides, but it has tons of downsides too.
    > I think your refs/audit/ idea should be given real thought, because
    > maybe that's the right idea.

    With the latest round of touch-ups, modulo a few bugs I will be fixing
    before the 1.7.8 final, I think what we have is more or less OK in the
    shorter term and should be ready for general consumption. The ugliness is
    gone, but the issue around internal signatures may remain to be solved in
    the longer term. At least, by storing the full contents of the tag today
    in an extended header, when we figure out how a detached signature should
    really work, we could convert by extracting them from the history.

    In a separate message earlier in the thread, you raised another issue.

    > I hate how anonymous our branches are. Sure, we can use good names for
    > them, but it was a mistake to think we should describe the repository
    > (for gitweb), rather than the branch.
    > Ok, "hate" is a strong word. I don't "hate" it. I don't even think
    > it's a major design issue. But I do think that it would have been
    > nicer if we had had some branch description model.

    At the first glance, our branch model is indeed peculiar in that a branch
    does not have a global identity. The scope of its name is local to the
    repository, and it is just a pointer into the history. A "note" [*1*] that
    can annotate a commit long after the commit is made is not a good way to
    describe what a branch is about, because the tip of the branch can advance
    beyond the commit that is annotated by such a note. A commit on a branch
    does not serve as a good anchoring point to describe the branch.

    However, a commit that merges the history of a branch, whether the merged
    branch is from a local repository or from a remote one, does serve as a
    good anchoring point. The work on a branch is finished as complete as
    possible at the time of the merge, and the committer who merges the branch
    agrees with both the objective and the implementation of the work done on
    the branch, and that is why the merge is made [*2*]. Describing what the
    history of the side branch was about in the resulting merge is a perfectly
    sensible way to explain the branch. So in that sense, I am very happy with
    the way the merge message template uses the pull request tag to let the
    lieutenant explain and defend the history behind the tag used for the pull
    request. Such an explanation does not have to be keyed with anybody's
    local branch name (e.g. "for-linus" would mean different things for
    different pull requests even from the same person), but keying it with the
    resulting merge commit is a sensible way to leave the record in the

    After justifying with the above two paragraphs that it is perfectly
    sensible to record the annotations on commits and not on "branch names", I
    do agree that we would eventually want to be able to have such annotations
    on commits after the fact. Neither "tags" nor "notes" is necessarily a
    very good mechanism, however, for the purpose of "signed pull requests"
    and "signed commits" [*3*]. Here are some pros and cons:

    - tags must be named, but the only thing we need is to be able to look
    the contents (with signature if signed) up given a commit object.
    Unlike the usual "I want to check out v3.0 release" look-up that goes
    from tag names to the commits, annotation look-ups go the other way, do
    not have to have a tagname, and having tagname does not help our
    look-up in any way. If we want to use tag to annotate various commits
    by various people and keep them around, we would need global namespace
    that would not cause them to crash (we can work this around by using
    the object name of the tag, e.g. renaming 'for-linus' tag to $(git
    rev-parse tags/for-linus), but that is merely a workaround of having to
    name things that do not have to be named in the first place). As a
    local storage machinery for annotations, tags hanging below refs/tags/
    (or refs/audit for that matter) hierarchy with their own names is an
    inappropriate model.

    + tags can auto-follow the commits when object transfer happens (at least
    in the fetch direction), and for the purpose of "signed pull requests"
    and "signed commits", this is a desirable property. When a repository
    gains a commit, the annotations attached to the commit that are missing
    from the receiving repository are automatically transferred from the
    place the commit comes from. Annotations given to other commits that
    are not transferred into the repository do not come to the repository.

    - "git notes" is represented as a commit that records a tree that holds
    the entire mapping from commit to its annotations, and the only way to
    transferr it is to send it together with its history as a whole. It
    does not have the nice auto-following property that transfers only the
    relevant annotations.

    + "git notes" maps the commits to its annotations in the right direction;
    the object name of an annotated object to its annotation.

    In the longer term, I think we would need to extend the system in the
    following way:

    - Introduce a mapping machanism that can be locally used to map names of
    the objects being annotated to names of other objects (most likely
    blobs but there is nothing that fundamentally prevents you from
    annotating a commit with a tree). The current "git notes" might be a
    perfectly suitable representation of this, or it may turn out to be
    lacking (I haven't thought things through), but the important point is
    that this "mapping store" is _local_. fsck, repack and prune need to be
    told that objects that store the annotation are reachable from the
    annotated objects.

    - Introduce a protocol extension to transfer this mapping information for
    objects being transferred in an efficient way. When "rev-list --objects
    have..want" tells us that the receiving end (in either fetch/push
    direction) would have an object at the end of the primary transfer
    (note that I did not say "an object will be sent in this transfer
    transaction"; "have" does not come into the picture), we make sure that
    missing annotations attached to the object is also transferred, and new
    mapping is registered at the receiving end.

    The detailed design for the latter needs more thought. The auto-following
    of tags works even if nothing is being fetched in the primary transfer
    (i.e. "git fetch" && "git fetch" back to back to update our origin/master
    with the master at the origin) when a new tag is added to ancient part of
    the history that leads to the master at the origin, but this is exactly
    because the sending end advertises all the available tags and the objects
    they point at so that we can tell what new tags added to an old object is
    missing from the receiving end. This obviously would not scale well when
    we have tens of thousands of objects to annotate. Perhaps an entry in the
    "mapping store" would record:

    - The object name of the object being annotated;

    - The object name of the annotation;

    - The "timestamp", i.e. when the association between the above two was
    made--this can be local to the repository and a simple counter would

    and also maintain the last "timestamp" this repository sent annotations to
    the remote (one timestamp per remote repository). When we push, we would
    send annotations pertaining to the object reachable from what we are
    pushing (not limited by what they already have, as the whole point of this
    exercise is to allow us to transfer annotations added to an object long
    after the object was created and sent to the remote) that is newer than
    that "timestamp". Similarly, when fetching, we would send the "timestamp"
    this repository last fetched annotations from the other end (which means
    we would need one such "timestamp" per remote repository) and let the
    remote side decide the set of new annotations they added since we last
    synched that are on objects reachable from what we "want".

    Or something like that.


    *1* By this word, I do not necessarily mean what the "git notes" command
    manipulates. A tag that points at a commit is also equally a good vehicle
    to annotate a commit after the fact.

    *2* For this reason, it may make sense to "commit -S" such a merge
    commit. The "mergetag" asserts the authenticity of the pull request from
    the lieutenant whose history is being integrated, and the "gpgsig" asserts
    the authenticity of the merge itself--the fact that it was made by the

    *3* I do not mean what "git commit -S" parked in 'pu' produces, which is
    to store the signature in the commit. Adding "Signed-off-by:" after the
    fact to an existing commit by many people is a more appropriate example.

     \ /
      Last update: 2011-11-09 18:29    [W:0.051 / U:18.564 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site