git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Fwd: [Survey] Signed push

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 14, 2011, 17:49 UTC
Message-ID
<7vobynui8a.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CA+55aFy0b+eozmzbKD4RXcJ7e3WCpf7BV1n1qXHOeEwSHZKOXw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 13 quoted lines
> 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 ;-)

Show 12 quoted lines
>> 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.
Show 7 quoted lines
> 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).

Show 6 quoted lines
> 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.
Previous: Linus TorvaldsNext: Sam Vilain
Message 33 of 62 in “[Survey] Signed push”
  1. Junio C HamanoSep 13, 2011
  2. 0/2 State commit name explicitly in request-pull messagesJunio C Hamano, Sep 13, 2011
  3. 1/2 fetch: allow asking for an explicit commit object by nameJunio C Hamano, Sep 13, 2011
  4. 2/2 request-pull: state exact commit object nameJunio C Hamano, Sep 13, 2011
  5. Guenter RoeckSep 13, 2011
  6. Junio C HamanoSep 13, 2011
  7. Junio C HamanoSep 14, 2011
  8. Sam VilainSep 14, 2011
  9. Shawn PearceSep 14, 2011
  10. Sam VilainSep 14, 2011
  11. Nguyen Thai Ngoc DuySep 14, 2011
  12. Jonathan NiederSep 14, 2011
  13. Nguyen Thai Ngoc DuySep 14, 2011
  14. Jeff KingSep 15, 2011
  15. Andy LutomirskiSep 14, 2011
  16. Junio C HamanoSep 14, 2011
  17. Andrew LutomirskiSep 14, 2011
  18. Fwd: [Survey] Signed pushLinus Torvalds, Sep 14, 2011
  19. Michael HaggertySep 14, 2011
  20. Matthieu MoySep 14, 2011
  21. Nguyen Thai Ngoc DuySep 14, 2011
  22. Johan HerlandSep 14, 2011
  23. Ted Ts'oSep 14, 2011
  24. Linus TorvaldsSep 14, 2011
  25. Matthieu MoySep 14, 2011
  26. Johan HerlandSep 14, 2011
  27. Philip OakleySep 14, 2011
  28. Linus TorvaldsSep 14, 2011
  29. Junio C HamanoSep 14, 2011
  30. Linus TorvaldsSep 14, 2011
  31. Junio C HamanoSep 14, 2011
  32. Linus TorvaldsSep 14, 2011
  33. Junio C HamanoSep 14, 2011
  34. Sam VilainSep 14, 2011
  35. request-pull: state what commit to expectJunio C Hamano, Sep 16, 2011
  36. Junio C HamanoSep 20, 2011
  37. 2/3 branch: teach --edit-description optionJunio C Hamano, Sep 20, 2011
  38. Andrew ArdillSep 21, 2011
  39. Junio C HamanoSep 21, 2011
  40. request-pull: use the branch descriptionJunio C Hamano, Sep 20, 2011
  41. 0/6 A handful of "branch description" patchesJunio C Hamano, Sep 22, 2011
  42. 1/6 branch: add read_branch_desc() helper functionJunio C Hamano, Sep 22, 2011
  43. 2/6 format-patch: use branch description in cover letterJunio C Hamano, Sep 22, 2011
  44. 3/6 branch: teach --edit-description optionJunio C Hamano, Sep 22, 2011
  45. Michael J GruberSep 23, 2011
  46. Nguyen Thai Ngoc DuySep 23, 2011
  47. Junio C HamanoSep 23, 2011
  48. Nguyen Thai Ngoc DuySep 25, 2011
  49. 4/6 request-pull: modernize styleJunio C Hamano, Sep 22, 2011
  50. 5/6 request-pull: state what commit to expectJunio C Hamano, Sep 22, 2011
  51. 6/6 request-pull: use the branch descriptionJunio C Hamano, Sep 22, 2011
  52. Michael J GruberSep 23, 2011
  53. Jeff KingSep 23, 2011
  54. Junio C HamanoSep 23, 2011
  55. Jeff KingSep 23, 2011
  56. Michael J GruberSep 24, 2011
  57. Jeff KingSep 27, 2011
  58. Annotated branch ≈ annotated tag?Michael Haggerty, Sep 28, 2011
  59. Andrew ArdillSep 28, 2011
  60. Michael HaggertySep 28, 2011
  61. Branch annotations [Re: Annotated branch ≈ annotated tag?]Michael J Gruber, Sep 28, 2011
  62. Jeff KingSep 29, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.