[Survey] Signed push

[administrivia] This message is also Cc'ed to the kernel mailing list in order to ask for opinions from members of one of the most important user communities of Git, but people may want to drop the kernel list when responding to this message to reduce the noise level over there. Thanks.

In the light of what happened to k.org recently, we've been discussing things Git can do to help raising confidence levels perceived by the general public on integrity of the source trees, especially for the kernel community. As the article by Jonathan Corbet on lwn.net nicely described, projects managed with Git are already pretty resistant from tampering, and it is not my (nor anybody in the Git community's) intention to propose any more unnecessary bureaucracy to the development process without merit.

There are two updates that may change the end user experience I would like to ask your opinions on, both as the Git designer (emeritus?) and as the top kernel developer.

1. Improved pull requests.

Currently a typical pull-request begins like this:

    The following changes since commit f696543dad6c7ba27b0c4fab167a5687263a9ba0:

      Flobar 2.4.3 (2011-09-13 12:34:56 +0900)

    are available in the git repository at:
      git://git.kernel.org/pub/flobar.git/ master

which is followed by the shortlog and expected diffstat. This tells you where the requester based his work on in excruciating detail, but does not tell you what you should expect to fetch, any more than "whatever happened to be at the named branch when you happened to notice the request."

We have a tentative patch to add an extra line after the "URL branch" line that is for your cut & paste that looks like:

    are available in the git repository at:
      git://git.kernel.org/pub/flobar.git/ master
    for you to fetch changes up to 5738c9c21e53356ab5020912116e7f82fd2d428f

I often see you respond to a pull request on the kernel mailing list with "I see nothing new; forgot to push?", and having this extra line may also help communication.

Would it be just an added and useless noise that you nor your requesters would not care much about?

An alternative that I am considering is to let the requester say this instead:

    are available in the git repository at:
      git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f

without adding the extra line.

That is, to allow fetching the history up to an explicitly named commit object. This would only involve a change to fetch-pack at the receiving end; just match the commit object name given from the command line against the ls-remote response and ask upload-pack to give the history leading to it. The released versions of Git already will happily oblige, as long as the commit object named in the request message still sits at the tip of the intended branch.

Do you think it is worthwhile to pursue this alternative?

2. Signed pushes.

You tag official releases and release candidates with your GPG key, and everybody who works within the kernel ecosystem trusts the history behind the commits pointed by them, but there is no easy way to verify that commits and merges between the last tagged commit and the tip of your branch(es) are indeed from you, or if an intruder piled fake ones on top of your commits (until you try to push again and discover that the history does not fast-forward, that is).

We have been discussing an addition of "git push -s" to let people sign their pushes (instead of having to sign every commit or add signed tag). The implementation alternatives were being bikeshed but not of much interest in this message, but the user experience would go like this:

 * You push out your work with "git push -s";

 * "git push" prepares a "push certificate" (it is meant to certify "these
   are the commits I place at the tips of these refs"), which is a human
   and machine readable text file in core, that may look like this:

        Push-Certificate-Version: 0
        Pusher: Junio C Hamano <gitster@pobox.com>
        Update: 3793ac56b4c4f9bf0bddc306a0cec21118683728 refs/heads/master
        Update: 12850bec0c24b529c9a9df6a95ad4bdeea39373e refs/heads/next

   and asks you to GPG sign it. You only unlock your GPG key and the
   command internally runs GPG, just like "tag -s".

 * When "git push" finishes, the receiving end has this record in its
   refs/notes/signed-push notes tree, together with your previous pushes
   (as this is not a shared repository, it will record only your pushes).
   The notes annnotate the commits named on the "Update:" lines above.

 * People who want to verify commits that are not yet tagged near the tip
   in their clone of your tree can fetch refs/notes/signed-push and run

     $ git log --show-notes=signed-push --branches --not --tags

   to see your push certificates as annotations on commits that are not
   yet tagged. They can verify them using a tool (yet to be written) that
   acts like "git tag --verify".

It is hoped that it would help downstream with warm and fuzzy assurances that all commits including the ones that are not yet tagged are genuine (disclaimer: my employer is among the "downstream" that wants to have that warm and fuzzy assurance) if we can see these push certificates published at your public repository.

A few questions.

 * As a user, do you think "signed push" is a good idea, or is it merely
   an unnecessary bureaucracy, having to sign all pushes?

 * As a user, do you think it is a good thing that you could also verify
   the commits you receive from the Git-managed repositories of your
   lieutenants using this mechanism, or you wouldn't bother, perhaps
   because you are applying many patches sent via unsigned e-mail from
   Andrew anyway?

 * If the answers to the above points are both "yes", do you think it
   would make sense to also propagate the push certificates you obtain
   from your lieutenants to your public repository when you make your
   "push -s"? It will allow your downstream to follow the chain of trust
   in one-go (if you are pulling from public places, they can fetch the
   push certificates from your lieutenants themselves and merge them, so
   this is merely a convenience feature) by simply fetching from the
   refs/notes/signed-push notes tree from your public repository.  Do you
   think it is a useful and worthwhile thing to do?

Here is an alternative approach to the earlier "request-pull" patch.

Junio C Hamano (2):
  fetch: allow asking for an explicit commit object by name
  request-pull: state exact commit object name

 git-request-pull.sh     |    2 +-
 remote.c                |   25 +++++++++++++++++++++++--
 t/t5150-request-pull.sh |   11 +++++++----
 3 files changed, 31 insertions(+), 7 deletions(-)

This teaches "git fetch" (hence "git pull") to accept an explicit commit object name in the LHS of the refspec, as long as the named commit is at the tip of an advertised ref. E.g.

    $ git pull origin 5738c9c21e53356ab5020912116e7f82fd2d428f
    $ git fetch origin 5738c9c21e53356ab5020912116e7f82fd2d428f:refs/remotes/origin

would behave exactly as if you asked

    $ git pull origin refs/heads/master
    $ git fetch origin refs/heads/master:refs/remotes/origin

when the output from "git ls-remote origin" said the remote side has the commit object whose name is 5738c9c21e53356ab5020912116e7f82fd2d428f at the tip of refs/heads/master branch ref.

This does not allow asking for a random object that may or may not exist in the repository (this has been a longstanding security feature).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 remote.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

A typical pull-request begins like this:

  The following changes since commit f696543dad6c7ba27b0c4fab167a5687263a9ba0:

    Flobar 2.4.3 (2011-09-13 12:34:56 +0900)

  are available in the git repository at:
    git://git.kernel.org/pub/flobar.git/ master

which is followed by the shortlog and expected diffstat. This tells you where the requester based his work on in excruciating detail, but does not tell you what you should expect to fetch, any more than "whatever happened to be at the named branch when you happened to notice the request."

Update the message slightly to say:

    git://git.kernel.org/pub/flobar.git/ 5738c9c21e53356ab5020912116e7f82fd2d428f ;# master

so that the line still can be cut&pasted after "git fetch" (or "git pull"), to form a command line that looks like:

    $ git <repository> <full commit object name> ;# branch

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-request-pull.sh     |    2 +-
 t/t5150-request-pull.sh |   11 +++++++----
 2 files changed, 8 insertions(+), 5 deletions(-)

On Tue, Sep 13, 2011 at 12:45:37PM -0400, Junio C Hamano wrote: [ ... ]

noise for me

[ ... ]

Excellent idea, long since overdue.

Guenter

Guenter Roeck <guenter.roeck@ericsson.com> writes:

Are you among the ones who respond to pull requests?

Junio C Hamano <gitster@pobox.com> writes:

Sorry, this didn't come out quite the way I intended.

As I do not know every developer on earth, I would like to know in what capacity you (figuratively---I mean everybody who gives his opinion on this topic) fit in your ecosystem. Otherwise I cannot tell if many people who receive pull requests find it noise but senders do not care, or many people who send them find it noise but receivers do appreciate, etc.

For the purpose of commenting on "pull requests" topic, one can be (1) a bystander, who does not request nor respond to pull requests, (2) who gets requests to pull, or (3) who sends requests to pull.

The same for "signed pushes". In this case, one can be (1) who pushes, (2) who fetches and wants to verify what he gets, (3) both (e.g. Linus playing role (3) while fetching from his lieutenants and then role (1) when pushing his integration results out).

On 9/13/11 9:45 AM, Junio C Hamano wrote:

If the push certificate also has the previous commit IDs for the changed refs, then you actually have an audit log. Otherwise, it does not certify the commit range they pushed.

This is an important prerequisite for a fully distributed, peer to peer git. For this case it would also need something to distinguish which repository is to be updated; such as a canonical repository URL (or list of URLs), or just a short project name. A P2P protocol can then know projects as (KEYID, projectname).

Sam

On Tue, Sep 13, 2011 at 17:31, Sam Vilain <sam@vilain.net> wrote:

Is that necessary? The range they are certifying is that commit, and its entire ancestry. If the pusher doesn't trust his ancestry, why is he working with it? Similar to an annotated tag. I make a signed annotated tag, I am asserting that revision and its ancestry is something I like as far as a project build goes. You don't need the old revision to realize I like this commit.

If you want to get into the game of, maybe I push a branch, then rewind it, and push something differently, and you want to be able to verify that the 2nd push is the "right thing" and the 1st push should be ignored, you can already see that by looking at the timestamp of the push certificates (/me assumes there is a timestamp in there). If you can create multiple signed pushes by yourself, using your GPG key, within the same second, and they are conflicting... well, stop using automated tools to create conflicting assertions as yourself. If you are creating signed pushes on systems with clock skew, learn how to configure NTP date.

Why do we need a project name? Most Git based projects are uniquely identified by the set of root commits they have. Why? Because most root commits were created by different people, at different times, with different commit messages, and different initial trees, resulting in a unique commit SHA-1 for that root commit. Projects with more than one root commit also disambiguate themselves from other projects that maybe contain one of those roots (e.g. git.git vs. gitk).

If you wanted to identify a project on a P2P network, I think you would want to do it based off the root commits, not some random name people came up with and might try to publish forgeries under.

On 9/13/11 5:39 PM, Shawn Pearce wrote:

Perhaps because they didn't notice what happened. Someone else pushed to the server without a signed push somehow, and then they pulled, pushed ... and now as far as you know, those commits are certified like any other. Having this extra information, not much information, will help figure out what happens in this sort of situation.

Yes, this is true, but it also makes it a lot harder to figure out if two projects are from the same real project, or whether they just shared some history. In general, git repositories are partitioned by URL or project, and so this makes a soft case for a distributed system to partition itself by URL or project also.

Sam

On Wed, Sep 14, 2011 at 2:45 AM, Junio C Hamano <gitster@pobox.com> wrote:

Stupid question, if we agree to go with signed push, can we also sign pull requests and verify them when we pull? I suppose most of the time, pulling can be done automatically by extracting pull url from the request. This would make pull/push both signed.

BTW, there's a third way (rsync is obsolete) to carry changes away in human-unreadable way: bundles. Should we also sign the bundles too (I guess we could just do the same as in signed push).

Nguyen Thai Ngoc Duy wrote:

[...]

If I understand you correctly, then ordinary PGP email signing[1] should work for that already. In your first example, the receiver can make sure whatever process grabs a pull request verifies it, and in the second example, the receiver checks the signature on her email before saving a bundle and passing it to "git fetch".

[1] http://www.phildev.net/pgp/gpgmua.html

On Thu, Sep 15, 2011 at 7:05 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

Yes, I think we can do that already. It's just more convenient to teach "git fetch/pull" to take pull requests and automatically verify them. Some repositories may also want to enforce signing and we can do that by setting config file and fetch/pull refuses if pull requests are not signed. We can also store the sign as git notes, just like in git-push (extra work if it has to be done manually).

On Thu, Sep 15, 2011 at 08:42:40AM +1000, Nguyen Thai Ngoc Duy wrote:

Isn't there a human element in the verification? I.e., I see a pull request, and we can computationally verify that it is signed by some key. Now assuming GPG's web of trust works, that binds that key to an email address and a real name. But how is that bound to the repository you are actually fetching from (or more appropriately, that the commits mentioned are appropriate to be pulled)?

That is a policy that the human must decide upon seeing "Oh, a pull request from developer X; I should pull that into my local branch Y", and which they do implicitly when they manually run the pull command mentioned in the email.

Another way to think of it is that verifying the identity of the sender (which GPG does) is only one step. You also need an ACL saying that the sender is worth pulling from.

So either:

  1. The human is still in the loop, in which case having git-pull
     verify the sender's identity hasn't really done anything (because
     probably their MUA already told them it was really from the
     purported sender, and then they made the ACL decision in their head
     before deciding to pull from you).

  2. The human is not in the loop, and nothing is checking that ACL.

-Peff

On 09/13/2011 09:45 AM, Junio C Hamano wrote:

I would love this feature on the pull/fetch interface, but for a completely different reason. Sometimes I want to pull a particular object (usually a commit, but sometimes just a tree or blob) from *myself*, and having to stick it on a branch is annoying.

One use-case is when applying a patch in git's extended format. If I know where it came from, I ought to be able to pull the blobs it depends on to enable three-way merge. I think that this is essentially impossible remotely right now.

Of course, merging with the result of the pull will result in terrible automatically-generated messages, but it's easy to fix that up manually.

This is one thing that I think Mercurial handles better than git. (And apologies for the noise if I've missed a way to do this with current git. I've looked, but maybe I missed some magic way to do this.)

--Andy

Andy Lutomirski <luto@MIT.EDU> writes:

I am afraind that it is not going to happen; see

    http://article.gmane.org/gmane.comp.version-control.git/181317

for a rationale.

On Wed, Sep 14, 2011 at 1:40 PM, Junio C Hamano <gitster@pobox.com> wrote:

Do you mean that it's a security feature? What if a .git/config option existed to allow this use? Or even a git upload-pack option that turned it *on* and was stripped by git-shell?

--Andy

Recovering lost emails. Or maybe you get duplicates. Sorry about that if so,

                   Linus

---------- Forwarded message ----------
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Tue, Sep 13, 2011 at 10:48 AM
Subject: Re: [Survey] Signed push
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, linux-kernel@vger.kernel.org

On Tue, Sep 13, 2011 at 9:45 AM, Junio C Hamano <gitster@pobox.com> wrote:

I think that would probably be a good idea, although I'd actually prefer you to be more verbose, and more human-friendly, and actually talk about the commit in a readable way. Get rid of the *horrible* BRANCH-NOT-VERIFIED message (that actually messes up pull requests if mirroring is a bit delayed and throws away more important information), and instead just have a blurb afterwards saying something human-readable like

 Top commit 1f51b001cccf: "Merge branches 'cns3xxx/fixes',
 'omap/fixes' and 'davinci/fixes' into fixes"

 and at *that* point you might have a "UNVERIFIED" notice for people
to check if they forgot to push.

So I'd much prefer something like that over:

The extra line in the pull request is cheap - it's not like we need to ration them. The above format, in contrast, requires that the person doing the *pull* have a recent enough git client, otherwise the merge commit message will be just horrible.

And even if you do have a new git client that turns the commit into a branch name, that's ambigious. What if both 'master' and 'experimental' have the same top commit, because experimental ended up being tested and was percolated to master? Which branch name would you pick? And what if the branch was updated since, so *no* branch name matches - does that mean that you'd disallow the pull entirely?

Also, if we're adding branch information, I'd say that a description of the branch is more important than a signature. Right now we lack even that.

It would be lovely if people could annotate their branches with descriptions, so that when I pull a "for-linus" branch, if it has a description, the description of the branch makes it into the merge message. Our merge messages are often not very informative.

I realize that cryptographic signature sound very important right now, but in the end, *real* trust comes from people, not from signatures. Realistically, I checked a few signatures this time around due to the k.org issues, but at the same thing, the thing that made me trust most of it was just looking at commits and the email messages. The unconscious and non-cryptographic "signature" of a person acting like you expect a person to act.

Technical measures can be subverted, and I think we should also think about the social side. Every time somebody mentions a signature, I want to also mention "human readability", because I think that matters as much, if not more.

So I'm not against signed pushes, but quite frankly, if you add some per-branch signature, I would argue against it unless that signature also comes with information that allows us to do a better job of human communication too. Like a branch description.

Imagine, for example, than when you do a

  git push -s ..

git would *require* you to actually write a message about what you are pushing. And when somebody pulls it, and creates a merge commit, that explanation would become part of the merge message. The "signature" part of the "-s" should be thought of as the *much* less interesting part - that's just a small detail that git can use to verify something, but it doesn't actually matter for the contents of the pull. Not like the actual human-readable message would.

Now *that* would be lovely. No?

                       Linus

On 09/14/2011 09:06 AM, Linus Torvalds wrote:

Instead of "like a branch description", why not implement branch descriptions directly?

I wish that one could annotate a branch (e.g., at creation) and have the annotation follow the branch around. This would be a useful place to record *why* you created the branch, your plans for it, etc. The annotation should be modifiable, because often a branch evolves in unforeseen ways during its lifetime. Anybody could read the annotation to get a quick idea of what kind of work is in progress.

Such a branch annotation could be used in pull requests, the cover letter of patch series emails, merge commit log messages, etc.

Michael

Michael Haggerty <mhagger@alum.mit.edu> writes:

Would the notes mechanism be able to annotate ref names instead of commit sha1?

On Wed, Sep 14, 2011 at 9:03 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Speaking from someone who has few experience with git-notes, no I don't think current git-notes can do that. But similar mechanism can be added, targeting ref instead of sha-1. But the question is, is branch description local or public?

Branch description sounds local to me. I just record a branch's purpose and status (the latter is more important to me). If it's local, we just need to extend ref format to store extra text in addition to SHA-1.

If it's public, perhaps if we have a good way to:
 - convert arbitrary text to a ref (maybe just converting spaces to hyphens)
 - specify a ref without writing the whole ref name (reminds me of
short sha-1 vs full sha-1)

then we could use branch name as branch description. The default merge commit messages can be updated to convert back branch name (which is also the branch description) to human-readable text.

On Wednesday 14. September 2011, Matthieu Moy wrote:

This has been discussed on the list before, but I'm too lazy to dig up a reference, so:

The notes mechanism can in principle annotate anything that has a SHA1 sum. The notes tree is really only a key->value mapping using SHA1s as keys and Git objects (typically blobs) as values.

HOWEVER, "git notes prune" will assume that the SHA1 keys are supposed to identify existing git objects, and will delete any note whose SHA1 key does not identify a reachable git object.

Hence, if you promise to never run "git notes prune" on refs/notes/branch-descriptions, you could use that ref to store your branch descriptions keyed by the SHA1 of your branch name.

The obvious deficiency with this scheme is that if your branch name is different in some repos, the branch description will be lost in those repos unless you rewrite the refs/notes/branch-descriptions notes tree accordingly.

...Johan

On Wed, Sep 14, 2011 at 02:28:52PM +0200, Johan Herland wrote:

It seems like notes is the wrong place to encode this. If people really want this, what if there was a convention where there could be a separate branch head: ref/heads/META

which contained a directory structure like this:

<e-mail>/key # The developer's GPG key <e-mail>/<tree>/URL # URL of developer's tree named <tree> <e-mail>/<tree>/description # Descrition of <tree> <e-mail>/<tree>/branch/<branch-name> # A description of that branch

etc.

Since it's a separate branch head, the contents can be pushed around and merged very easily, and there's no danger of the information getting lost via a garbage collection or prune operation.

If there was an association between a local branch and <e-mail>/<tree> that it was tracking, then either a modified git core or porcelein command could get the information from the META tree. It would also make it easy to fetch a developer's GPG key without having to go to outside GPG key servers, which is a minor benefit (although maybe that's not worth it).

	     	   	   	      	 - Ted

On Wed, Sep 14, 2011 at 4:03 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

That would be a horrible, horrible notion.

It's quite common to have multiple branches with the same SHA1. It might be in the "experimental-development" branch, but it got through testing with flying colors and deemed to be stable, so it got upgraded to the "for-linus" branch, and there hasn't been any other development since. So now both "for-linus" and "experimental-development" are the same commit, but they are very much not the same branch!

So no, don't confuse branch *contents* with branch *descriptions*.

                          Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

That's why my question was about annotating ref _names_, yes. As Johan Herland pointed out, this would be possible in theory, but not really in practice.

On Wednesday 14. September 2011, Linus Torvalds wrote:

I don't think the suggestion was about annotating the branch tip as a way of describing the branch. Rather, you create a _new_ SHA1 that identifies the branch (e.g. SHA1(branch_name) ), and then annotate _that_ SHA1. As I said, that _can_ be done with the notes infrastructure, but - as Ted noted - there might be better solutions to storing branch descriptions.

...Johan

From: "Johan Herland" <johan@herland.net>
.

Is one option to store the branch description (if any) on line two of the <branch name> file in .git\refs\heads. That is, from byte 42 onward, after the 40 byte sha1 and its LF. Older systems would simply overwrite it, while newer systems would be able to read it. The fixed format of the first 41 chars alllows sensible checks in the various places it is used.

Philip Oakley 

On Wed, Sep 14, 2011 at 3:51 PM, Philip Oakley <philipoakley@iee.org> wrote:

Or even on line one.

We already basically do that for the magic FETCH_HEAD branch, and use it to populate the merge commit. Extending that kind of thing to all branches might be a nice idea.

Of course, then the question becomes "what about packed refs"? Do you just leave the unpacked ref in place for those?

                          Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

Seriously, storage format is not an issue at all and you know it. The semantics is.

What commands use the description and for what purpose, how it is updated when the branch is repurposed, how it is propagated to other repositories, if there is a situation where two descriptions need to be merged, and if so how that merge happens, etc., etc.

We could store it in unused part of loose refs. We could add [branch "master"] description = ... in the .git/config. The latter would even be easier for humans to edit by hand.

If we want to use the description when merging locally, for example, fmt-merge-msg needs to be taught to read it, which would mean we would need an internal API "read_branch_description()", regardless of what storage format we choose to use. If we want to use it for "git pull", then the transport layer needs to become aware of it.

On Wed, Sep 14, 2011 at 3:45 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:

Mostly because of just human interface issues.

We already have a "repository description", and it's quite commonly never even filled in. For branches, that would be doubly true, because a lot of branches are throw-away.

So I think it would work if we made it part of of something like "git push -s" - because that's when it starts mattering to others.

I wouldn't be against that as a concept, I just think you'd be a small small minority, and most branches would never get annotated.

But I don't really care deeply how it actually works - my main issue is that git makes it way too easy to have bad merge messages. I think part of that is an even simpler idiocy: we never even fire up the editor by default for a "git merge", but we do for a "git commit". That was a design mistake, and it means that if you want to actually add a note to a merge, you have to do extra work. So people don't.

Now people do "git merge" in scripts etc, so we can't fix it ;-(

                    Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

Yes you can, by teaching "git merge -e" to open an editor ;-).

In the meantime, "commit --amend" is your friend.

On Wed, Sep 14, 2011 at 10:52 AM, Junio C Hamano <gitster@pobox.com> wrote:

The problem with both of those are human: because it's extra work, it's not going to get done.

In contrast, if it's extra work to *avoid* editing the merge message, people probably would see the editor pop up, and start adding a few small notes.

That's why "default behavior" matters so much. It's not that it's not *possible* to edit a merge message, it's that nobody ever does!

                        Linus

Linus Torvalds <torvalds@linux-foundation.org> writes:

That UNVERIFIED thing was neither my favorite nor my idea, and I'd happily rip it out in any second ;-)

In a re-roll patch I've added ";# branch-name" at the end of that line for people with older git, but existing git wouldn't allow you to fetch anything but refs so you won't risk getting "just horrible" merge message ;-)

You are right about ambiguities, but when the specified commit does not match the branch, it was indeed my intention to claim it is a _feature_ that pull fails, as you would be getting something different from what you thought was promised by the requester with bait-and-switch.

I do not particularly want to go into that tangent, and I do agree with your later message in this thread that it may make sense to tie the publishing (and possibly recording) of the description of the branch to "push -s"; people simply do not have reason to name throw-away branches.

I'm wondering if this could be something we can share between the push certificate "Into this repository, I pushed this commit to that branch, whose pupose is..." and pull request "...so please pull it to merge into your history." There are three possibile orders of things a lieutenant or a contributor may want to do after perfecting his tree locally:

 (1) Write pull-request, and then "push -s".

 (2) "push -s", and then write pull-request.

 (3) "push -s" auto-mailing a pull-request.

I obviously agree 100%, but that is an argument against trusting only technical measures---right now, we do not have a good technical measure to validate latest commits not yet contained in any tagged releases.

A piece of e-mail to the kernel list from you that says "I pushed it out and the tip is this SHA-1", if it is written in good English with a bit of your usual humor sprinkled in, would in practice be just as good as GPG for the kernel list regulars who can recognize your style and serve as that "technical measure" (by the way "What's cooking" does have the tips of master and next branches for this exact reason).

Yeah, we could go in that direction.

[re-send as text-only.  sorry, new system]

On 9/14/11 10:49 AM, Junio C Hamano wrote:

If the system is watertight enough, then you could have verified pushes ONLY under some new refspace, like:

refs/forks/forkid/branch

"forkid" is set up when you choose to "follow" someone's pushes. ie, you say something like:

git fork follow linustorvalds@osdl.org <http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x17762C4676E21CBB>

"torvalds@osdl.org" here representing a PGP key ID search string. It could be instead, "0x17762c4676e21cbb"

And then the "refs/forks/linus/xxx" space gets populated as signed pushes are seen on the network (perhaps when fetching from a pull request, or perhaps via a service). A configuration option can be set to warn if you are not merging a signed branch. If the new "pull request/push" object is a distinct object type or tag object, then it could be the destination of the 'refs/forks/...' ref, and the branch desription and hence the default merge message be retrieved from that.

Sam

Junio C Hamano <gitster@pobox.com> writes:

So this is the third round.

-- >8 -- The message gives a detailed explanation of the commit the requester based the changes on, but lacks information that is necessary for the person who performs a fetch & merge in order to verify that the correct branch was fetched when responding to the pull request.

Add a few more lines to describe the commit at the tip expected to be fetched to the same level of detail as the base commit.

Also update the warning message slightly when the script notices that the commit may not have been pushed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

A UI wart that we cannot fix without breaking backward compatibility is that the "end" parameter (which defaults to HEAD and is assigned to $head variable in the script) the requestor uses from the command line names a commit (often the name of a local branch), but for the purpose of telling which ref to pull from the public repository, that is a _wrong_ thing to give to the recipient.

Because the act of generating a request-pull message and the act of pushing to the public repository are not linked in any way, the script does not know _how_ the requestor caused (or intends to cause) the commit to sit at the tip of which branch. There is no guarantee that a lazy "git push" that relies on the configured refspec will be (or have been) used, so even parsing the output from "git push -n --porcelain -v $there" would not tell the script which branch the commit to be pulled is to be pushed out to, or if the branch is consistent with the request message.

The use of "git ls-remote" in the script and picking one of the refs that matches the commit object at random from its output is unsatisfactory, but that is unfortunately the best this script could do without correcting the design mistake and redefining what the "end" parameter means.

If we can break the backward compatibility and redefine that the "end" parameter now means the name of the branch at the public repository, it would make the operation a lot more robust. We could then:

 - $branch is what is given by the end user (it is an error not to give
   the "end" parameter);
 - run "git ls-remote $url $head" to find $headrev;
 - generate the message and shortlog using the information obtained from
   $url; and
 - get rid of "did you forget to push" message.

We could allow adding yet another argument which names a commit object locally, and make sure if the $headrev observed by ls-remote does not match it.

---
 git-request-pull.sh     |   34 +++++++++++++++++++---------------
 t/t5150-request-pull.sh |    6 ++++++
 2 files changed, 25 insertions(+), 15 deletions(-)

Here are three patches on top of the latest round of request-pull update. The first two are to add a new option to "git branch" command so that a descriptive text that explains what the purpose of the branch is, for use by other commands. And the last one builds on top of the patch this message is a response to, to use that information.

And here is the first one, just an unrelated doc clean-up.

-- >8 --
Subject: [PATCH 1/3] branch doc: minor formatting fix

We tend to use typewriter font when writing command flags that are meant to be typed literally by the user.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-branch.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Using branch.$name.description as the configuration key, give users a place to write about what the purpose of the branch is and things like that, so that various subsystems, e.g. "push -s", "request-pull", and "format-patch --cover-letter", can later be taught to use this information.

The "-m" option similar to "commit/tag" is deliberately omitted, as the whole point of branch description is about giving descriptive information (the name of the branch itself is a better place for information that fits on a single-line).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-branch.txt |    5 +++
 builtin/branch.c             |   68 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 71 insertions(+), 2 deletions(-)

On 21 September 2011 09:02, Junio C Hamano <gitster@pobox.com> wrote:

I understand your reasoning here, however is there a way to allow setting the branch description in, for example, a script?

Additionally I can imagine it would be useful to be able to set the branch description from another tool, what is the recommended way of doing that? Should tools modify the config directly??

Regards, Andrew

Andrew Ardill <andrew.ardill@gmail.com> writes:

As you read in the patch, especially the documentation part, there is not a way to do that.

I am not interested because it does not directly help my cause of helping the human communication between the kernel developers who may want to perform a signed push to their public repository and send their pull requests with the same message to Linus.

That does _not_ mean I will _reject_ a patch to add such a feature. It just means writing such a patch myself or reviewing and accepting such a patch is not very high in my prioritized list at this point in the evolution of the series. Teaching the use of the information to other commands such as "format-patch --cover-letter" would have much higher precedence.

An obvious answer: "do whatever you want". The only rule that the programs that need to follow is that branch.$name.description has the string to use to obtain the explanation text.

How they achieve that (perhaps by running "git config") is of secondary importance.

Now we have branch descriptions stored in the repository, we can use it when preparing the request-pull message.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-request-pull.sh |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

Here are a few patches that I have queued in 'pu', redoing some of the patches I already sent out to the list, around "branch description".

The original motivation was to make the push/pull workflow appear more robust by allowing human-to-human communication to leave audit trail that can be verified when it becomes necessary. Namely:

 * request-pull message carries the SHA-1 of what is expected to be
   merged; and

 * "signed push" leaves the SHA-1 of what was pushed to the remote,
   cryptographically signed.

Linus's reaction, as I understood him, was "if we are spending efforts to add more information, the end result should be more informative to humans not just to machines", and I agree. An example of piece of information we often talk about is branch description---what a particular branch is meant to achieve. Both request-pull messages and declarations of what was pushed are good places to record that piece of information.

So here is a partially re-rolled series to get us closer.

 * The logic to read from an existing branch description was in
   builtin/branch.c in the original series, but the first patch separates
   it out into branch.c as a helper function;

 * The second one is a digression; the branch description describes what
   the topic aims to achieve, so it was natural to use it to prime the
   cover letter while preparing a patch series with format-patch;

 * The third one that adds "branch --edit-description" is basically
   unchanged modulo small leakfix from the original round;

 * And the remainder of the series for request-pull is the same as the
   last round.

The second patch uses facility introduced in bk/ancestry-path topic, so it would be the easiest to apply the series on top of a merge of c05b988 to 'master'.

I haven't updated the "signed push" patch to use this information yet.

Junio C Hamano (6):
  branch: add read_branch_desc() helper function
  format-patch: use branch description in cover letter
  branch: teach --edit-description option
  request-pull: modernize style
  request-pull: state what commit to expect
  request-pull: use the branch description

 Documentation/git-branch.txt |    5 +++
 branch.c                     |   31 ++++++++++++++++++
 branch.h                     |    5 +++
 builtin/branch.c             |   56 +++++++++++++++++++++++++++++++-
 builtin/log.c                |   71 +++++++++++++++++++++++++++++++++++++++--
 git-request-pull.sh          |   73 ++++++++++++++++++++++++++---------------
 t/t5150-request-pull.sh      |    6 +++
 7 files changed, 215 insertions(+), 32 deletions(-)

This will be used by various callers that make use of the branch description throughout the system, so that if we need to update the implementation the callers do not have to be modified.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 branch.c |   31 +++++++++++++++++++++++++++++++
 branch.h |    5 +++++
 2 files changed, 36 insertions(+), 0 deletions(-)

Use the description for the branch when preparing the cover letter when available.

While at it, mark a loosely written codepath that would do a random and useless thing given an unusual input (e.g. "^master HEAD HEAD^"), which we may want to fix someday.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 branch.c      |    2 +-
 builtin/log.c |   71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 2 files changed, 69 insertions(+), 4 deletions(-)

Using branch.$name.description as the configuration key, give users a place to write about what the purpose of the branch is and things like that, so that various subsystems, e.g. "push -s", "request-pull", and "format-patch --cover-letter", can later be taught to use this information.

The "-m" option similar to "commit/tag" is deliberately omitted, as the whole point of branch description is about giving descriptive information (the name of the branch itself is a better place for information that fits on a single-line).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/git-branch.txt |    5 +++
 builtin/branch.c             |   56 ++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 59 insertions(+), 2 deletions(-)

Junio C Hamano venit, vidit, dixit 23.09.2011 00:09:

I don't think that is the only reason why we should not make "git branch -m foo bar" set the description "foo" for branch "bar"...

Granted, your argument applies to "--set-description" ("-m"-like) also.

Michael

;)

On Thu, Sep 22, 2011 at 03:09:19PM -0700, Junio C Hamano wrote:

I suppose a Windows editor mave save the description with \r\n ending. Perhaps a patch like this to avoid messing up config file?

--8<--
Subject: [PATCH] config: quote \r in value

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 config.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

Doesn't stripspace() cleanse that already?

On Sat, Sep 24, 2011 at 5:04 AM, Junio C Hamano <gitster@pobox.com> wrote:

Yes, isspace() indeed treats \r as a space and stripspace() does the right thing.

Make it a bit more conforming to Documentation/Codingstyle

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-request-pull.sh |   29 +++++++++++++----------------
 1 files changed, 13 insertions(+), 16 deletions(-)

The message gives a detailed explanation of the commit the requester based the changes on, but lacks information that is necessary for the person who performs a fetch & merge in order to verify that the correct branch was fetched when responding to the pull request.

Add a few more lines to describe the commit at the tip expected to be fetched to the same level of detail as the base commit.

Also update the warning message slightly when the script notices that the commit may not have been pushed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-request-pull.sh     |   34 +++++++++++++++++++---------------
 t/t5150-request-pull.sh |    6 ++++++
 2 files changed, 25 insertions(+), 15 deletions(-)

Now we have branch descriptions stored in the repository, we can use it when preparing the request-pull message.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 git-request-pull.sh |   20 +++++++++++++++++++-
 1 files changed, 19 insertions(+), 1 deletions(-)

Junio C Hamano venit, vidit, dixit 23.09.2011 00:09:

I'm afraid I've missed the first installment of the series, or rather the fact that it was about more than just signed pushes. I've been working at (and with) branch and tag annotations for quite a while now and should have probably pushed the WIP rather than just dropping the occasional note. So I'll describe briefly what I have (the branches are in any of my repos[1]), which is notes based:

  mjg/vob/branch-notes [mjg/vob/virtual-objects: ahead 4]
    Annotations for branches and tags
    
    Show notes for branches and tags when "branch" resp. "tag" is called with "--notes".
    The "--notes" argument can take on all usual forms.

  mjg/vob/format-patch-branch-note [mjg/vob/refrev-hash: ahead 1]
    Cover letter from notes
    
    Fill in the cover letter from a note to ref:HEAD if --notes is given.
    TODO: The current branch may not be the one the format-patch arguments refer to.

  mjg/vob/refrev-hash [mjg/vob/virtual-objects: ahead 2]
    Pseudo revs for refnames
    
    Introduce "ref:foo" to denote the (virtual) refname object for the ref named
    "foo". This is handy for now (editing branch and tag notes) but should
    become obsoleted by a better ui, such as "git branch --edit foo" or
    "git notes --refname edit foo".
    
    Introduce "ref:" as a shortcut to "ref:HEAD" which is the refname object
    for the current branch.

  mjg/vob/refrev-pretend [mjg/vob/virtual-objects: ahead 1]
    Pseudo revs for refnames
    
    An alternative implementation using pretend_sha1...
    Currently unused.

  mjg/vob/virtual-objects [origin/next: ahead 2, behind 10]
    Virtual refname objects
    
    For each existing refname, introduce virtual objects corresponding to a blob
    with the refname as the content. "virtual" refers to the fact that these
    objects are not written out but exist for all other purposes, such as
    attaching notes and keeping them from being pruned.

  mjg/vob/virtual-refs-for-rnos
    Virtual refs for refname objects
    
    For each ref, pretend that the corresponding refname object is referenced
    to keep it from being pruned. This still requires branch note code to
    write out these objects.
    (Unused earlier approach.)

  mjg/vob/virtual-refs-pretend-all
    Virtual refs for refname objects
    
    For each ref, pretend that the corresponding refname object is referenced
    to keep it from being pruned. This still requires branch note code to
    write out these objects.
    (Unused earlier approach using pretend_sha1....)

Yes, the above is (with added newlines and removed top commit info) the output of 'git branch -vv --notes --list mjg/vob\*' :)

Open questions:
* Should the refname object for ref "foo" really be identical to a blob with content "foo"? Or content "ref: foo? Or...?
* Should ref (branch and tag) annotations use the same default notes tree as commit notes?
* How best to view annotations on remote branches? This is connected with open questions about notes sharing and the ref namespace structure.

I do think that config based descriptions are a quick solution, but a very non-distributed, non-versioned approach when compared to the notes approach.

Michael

[1] git://github.com/gitigit/git.git git://gitorious.org/~mjg/git/mjg.git git://repo.or.cz/git/mjg.git

On Fri, Sep 23, 2011 at 10:56:47AM +0200, Michael J Gruber wrote:

Eww. :)

This seems like a clever solution to making git-notes store a ref as a key instead of an arbitrary sha1. But I wonder if the end result is really waht the user wants. The resulting notes tree is good for doing lookups, but the entries are completely obfuscated. So I can't easily do something like "list all of the refs which have descriptions". I can only list the _hashes_ of the refs which have descriptions. And if I am lucky, I can hash the refs I have and correlate them. But unknown ones will simply be a mystery.

Wouldn't it be much more friendly to have a separate tree of refnames that stores:

  refs/heads/foo -> (some blob with the "foo" description)
  refs/heads/bar -> (some blob with the "bar" description)

Yeah, you have to build another git-notes-like interface around it. But the data structure is pleasant and flexible. You could even "git checkout" the whole tree and edit the notes with your editor, without having to deal with some obfuscated name.

-Peff

Jeff King <peff@peff.net> writes:

A more fundamental issue I have with this is that names of the refs are local by nature (what I call "master" branch is not "master" to you, but rather it is "origin/master" or "jch/master") while notes is meant to be the mechanism to share. The following shares the same issue, but at least it does not abuse "notes", so in that sense it may be cleaner at the design level...

On Fri, Sep 23, 2011 at 01:52:10PM -0700, Junio C Hamano wrote:

Good point. For that reason, your config-based solution perhaps makes more sense.

-Peff

Jeff King venit, vidit, dixit 23.09.2011 22:18:

[mjg@localhost git]$ git rev-parse ref:mjg/vob/virtual-objects 3f8aa9bb80fe241306aafd3d76af50739ba88268 [mjg@localhost git]$ git show 3f8aa9bb80fe241306aafd3d76af50739ba88268 refs/heads/mjg/vob/virtual-objects

:)

The only problem is with notes for non-existing refs. [You only have to invoke the inverse mapping to sha1, of course... Uhm.]

Given the above, I don't think it's more friendly.

In fact, in my first attempt, I wrote out the blobs, and referenced them just like above from a different subtree within the notes tree, in order to keep them from being pruned. So the virtual approach is pretty equivalent, though leaner.

Well, "git branch --edit-description" and such should be the way to edit them, shouldn't it?

I really think the only issue is remote refnames. As Junio points out, they are local by nature. OTOH, you typically use a non-renaming refspec which puts them under refs/remotes/foo/bar with "bar" being the same name as the local one on the remote, foo something you have chosen. So, teaching the code that the note for

refs/remotes/foo/bar

is in the notes tree

refs/remotes/foo/notes/commits (or .../refames, or whatever we do with the namespaces)

as a note attached to sha1("refs/bar")

is really a non-issue. It's not done yet, in part because of the possible namespace restructuring.

Michael

On Sat, Sep 24, 2011 at 04:42:18PM +0200, Michael J Gruber wrote:

Sure, but what about:

  git notes list

which is just filled with meaningless nonsense.

Hmm. So your mapping of $ref to $desc is:

  sha1($ref) -> sha1(blob($desc))

  sha1(blob($ref)) -> sha1(blob($desc))

But what I meant was actually:

  $ref -> sha1(blob($desc))

I.e., not to use "notes" at all, but rather a tree that mirrors the refs/ hierarchy in its names.

It's one way. I assume that if we store things in a reasonable, readable state, then people like that because they can hack on the data structure using more flexible tools.

If they are local by nature, is it worth putting them into a notes tree at all? That provides versioning and backup. But I wonder if it is worth the hassle, when one could just put them in the config.

-Peff

On 09/27/2011 11:58 PM, Jeff King wrote:

I don't think that branch descriptions should be local-only. They would be a good way to share information with others about work in progress.

It seems to me that an annotated branch is very much like an (unsigned) annotated tag, except that it is movable and disposable like a normal branch. What would be the ramifications of using an annotated-tag-like object to record metainformation about a branch? (Let's just call it an "annotation object" for this discussion.)

* The branch would point not at a commit but at an annotation object
that points at a commit.

* Obviously, a new annotation object would have to be written every time
the branch is updated.

  * Presumably, by default, the old description would be copied from the
old annotation object to the new one; the committer would be set to
those of the user doing the update.

  * The old annotation object would become unreachable after every
branch update, though locally it would still be reachable via the
branch's reflog [1].

* Creating a new branch from an annotated branch should perhaps open an
editor to allow the user to set a new comment.  If the user deletes the
whole comment in the editor, then an unannotated branch is created
instead of an annotated branch.

* We would need rules for merging annotation objects:

  * There is no such thing as a fast-forward merge to an annotated
branch, because the merged-from branch, even if annotated, can never
have the merged-to annotation object in its history.  So proceed to the
following rules.

  * If both branches are unannotated, then the result should be an
unannotated branch (like today).

  * If both branches have the same comment, the comment should be
carried over to the result without prompting.

  * If the merge-to branch is annotated and the merge-from branch is
not, keep the merge-to branch's annotation.

  * If the merge-to branch is unannotated and the merge-from branch is
annotated, the result should be a conflict.  This cannot be resolved
automatically because there are two likely scenarios:

    * A remote branch is being merged into a remote-tracking branch.  In
this case somebody upstream probably added a comment to the branch, and
one would like to preserve this comment in a local annotated branch.

    * A feature branch is being merged back to mainline.  In such a case
one would *not* like to carry over the branch annotation (which
presumably describes the feature that was developed on the branch),
though it would often be convenient to integrate the merged-from branch
annotation into the log message of the merge commit.

    I'm not sure how to let the user distinguish between the two cases
above, but it probably involves $EDITOR.

  * If the merge-to branch and the merge-from branch have conflicting
annotations, there are two possibilities much like in the previous case.

* Annotated tag objects include the name of the tag that is being
annotated.  Annotated branch objects should *not* include this
information, because it does not carry across from one repo to another
when branches are renamed.  (Perhaps the presence/absence of the tag
name could be what distinguishes an (unmovable) annotated tag object
from a (movable) annotated branch object.)

It would even be possible to allow signatures in the annotated objects; these could play the role of push certificates. Whenever a signed annotated branch is updated, the signature would go away (it would probably be too cumbersome to prompt the user to generate it a new signature for every branch update). It should be easy to add a signature to an existing annotated or unannotated branch (writing a new annotation object, of course).

ISTM that the semantics would be very close to what is desired, and would satisfy a few needs: a place to describe work-in-progress in a sharable way, branch descriptions that can be used for constructing pull requests and merge commit messages, and (optionally) a way to implement signed pushes. It would surely be a lot of work to implement, but being based on annotated tags would mean that a lot of code, documentation, and training would be common to the two concepts.

Michael

[1] If the retention of annotation history were considered a requirement, the annotation object could record as a "parent" the object name of the annotation object that it is succeeding. But I don't think that this is a good idea; it would make branches too heavyweight and every branch update would be recorded permanently, both of which are contrary to the git philosophy.

On 28 September 2011 14:23, Michael Haggerty <mhagger@alum.mit.edu> wrote: [snip]

If this was required, a better way would be to update the parent object only if the description changed. You would then have a nice little DAG that records changes to the description and could be used in 3-way merges etc. You would of course get lots of 'dead' annotation objects pointing to the previous change, however that shouldn't be too much of an issue.

At this point, however, I ask how is an annotation object any different to placing an annotation file in our repository. Perhaps there is no difference, except that one is a convention and the other is provided.

Regards, Andrew

On 09/28/2011 09:12 AM, Andrew Ardill wrote:

Yes, if history is being preserved, then the annotation objects would not be much different than storing a file in the repository. But even then, there are differences:

- A branch annotation would be separate from the source code and not
appear in the working tree, which seems more appropriate for metadata.

- git and other tools would know where to find the annotation instead of
having to configure whether a particular project uses annotations and if
so where to find them.  This would make it easier to use the annotations
in git workflow like the generation of pull requests.

- The merge rules for annotations would be different than those for
other files.

But I believe that branch annotation history should *not* be retained, so storing the annotations in the source tree is not even an option (except perhaps in another artificial branch used only for annotations).

Michael

I'm not tied to a particular implementation (not even mine), but we should think through the concept before baking something in. That was my impetus for throwing in a (half-baked) notes based solution before a config based is baked^Wset in stone ;)

For me, commit annotations as currently implemented (notes) have the following positives:

* easy ui (add/edit/copy)
* easy scripting (-F/-m)
* can be shared *if I want* (by pushing refspec; note that share=backup
as well as share=publish, depending on where I push to); ui could be
somewhat better
* multiple sources possible
* is versioned (ui could be better, e.g. git notes log)

For branch annotations, I would want to have all of the above. Depending
on the use case, I want to treat branch annotations as purely local (but
may still want to push them to backup) or share and publish them. I
might be interested in their history or not, etc. In addition, we would
want to have the obvious:
* git branch -m moves annotation
* git branch --list --younameit shows annotation
* etc.

If we agree that we want the above properties (and that is a big if) then using notes seem very natural. [Having to rewrite an annotated tag object at each branch head change appears unnatural.] They should probably live in a separate default tree (one per remote for remote branches), and the actual mechanics (virtual objects, real objects, textconvcache like...) is not dictated by those requirements.

Note though that we might be interested in annotating more general names than just refnames, e.g. paths, or names like "description". Since tags should be immutable, adding notes to a tag seems not much different from annotating the referenced commit, but it is different in concept and could be treated differently (as tag notes would be in a separate tree from the commit notes tree).

So, if we want to keep that path open (annotate more general names), a mapping from names to notes becomes mandatory. Again, that does not dictate a specific implementation.

Michael

On Wed, Sep 28, 2011 at 06:23:23AM +0200, Michael Haggerty wrote:

Leaving aside for a moment whether this is a good system or not, I think it's infeasible at this point simply because it is so far from what current git does, and in such a visible way.

Consider the interactions between this system and older versions of git. Won't all of the older clients see this annotation cruft at the tip of each branch? How will they react? It would no longer be correct to make commits with "git commit-tree $tree `git rev-parse HEAD`", would it?

-Peff