Subject: Re: Fwd: [Survey] Signed push

From: Junio C Hamano <[email-masked]>
Date: Wed, 14 Sep 2011 10:49:41 -0700

Linus Torvalds <[email-masked]> writes:

> 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.

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

>> 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.
>
> 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.

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 ;-)

> ... And what if the branch was updated since, so *no* branch name
> matches - does that mean that you'd disallow the pull entirely?

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.

> 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.

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.

> 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.

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 realize that cryptographic signature sound very important right now,
> but in the end, *real* trust comes from people, not from signatures.
> ...
> 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.

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).

> 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.

Yeah, we could go in that direction.