From: Junio C Hamano <gitster@pobox•com>
To: Linus Torvalds <torvalds@linux-foundation•org>
Cc: git@vger•kernel.org
Subject: Re: Fwd: [Survey] Signed push
Date: Wed, 14 Sep 2011 10:49:41 -0700 [thread overview]
Message-ID: <7vobynui8a.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CA+55aFy0b+eozmzbKD4RXcJ7e3WCpf7BV1n1qXHOeEwSHZKOXw@mail.gmail.com> (Linus Torvalds's message of "Wed, 14 Sep 2011 00:06:37 -0700")
Linus Torvalds <torvalds@linux-foundation•org> 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.
next prev parent reply other threads:[~2011-09-14 17:49 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-13 16:45 [Survey] Signed push Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 0/2] State commit name explicitly in request-pull messages Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 1/2] fetch: allow asking for an explicit commit object by name Junio C Hamano
2011-09-13 22:28 ` [PATCH v2 2/2] request-pull: state exact commit object name Junio C Hamano
2011-09-13 23:26 ` [Survey] Signed push Guenter Roeck
2011-09-13 23:50 ` Junio C Hamano
2011-09-14 0:02 ` Junio C Hamano
2011-09-14 0:31 ` Sam Vilain
2011-09-14 0:39 ` Shawn Pearce
2011-09-14 1:03 ` Sam Vilain
[not found] ` <CA+55aFxAQTR3sT7gekAD4qih8J+z-qwri7ZmNCPUd811xgci6w@mail.gmail.com>
2011-09-14 7:06 ` Fwd: " Linus Torvalds
2011-09-14 10:45 ` Michael Haggerty
2011-09-14 11:03 ` Matthieu Moy
2011-09-14 11:46 ` Nguyen Thai Ngoc Duy
2011-09-14 12:28 ` Johan Herland
2011-09-14 12:56 ` Ted Ts'o
2011-09-14 15:27 ` Linus Torvalds
2011-09-14 15:42 ` Matthieu Moy
2011-09-14 16:14 ` Johan Herland
2011-09-14 22:51 ` Philip Oakley
2011-09-14 23:30 ` Linus Torvalds
2011-09-14 23:44 ` Junio C Hamano
2011-09-14 15:25 ` Linus Torvalds
2011-09-14 17:52 ` Junio C Hamano
2011-09-14 18:36 ` Linus Torvalds
2011-09-14 17:49 ` Junio C Hamano [this message]
2011-09-14 20:52 ` Sam Vilain
2011-09-16 19:04 ` [PATCH v3] request-pull: state what commit to expect Junio C Hamano
2011-09-20 23:01 ` Junio C Hamano
2011-09-20 23:02 ` [PATCH 2/3] branch: teach --edit-description option Junio C Hamano
2011-09-21 0:15 ` Andrew Ardill
2011-09-21 2:44 ` Junio C Hamano
2011-09-20 23:03 ` [PATCH] request-pull: use the branch description Junio C Hamano
2011-09-22 22:09 ` [PATCH 0/6] A handful of "branch description" patches Junio C Hamano
2011-09-22 22:09 ` [PATCH 1/6] branch: add read_branch_desc() helper function Junio C Hamano
2011-09-22 22:09 ` [PATCH 2/6] format-patch: use branch description in cover letter Junio C Hamano
2011-09-22 22:09 ` [PATCH 3/6] branch: teach --edit-description option Junio C Hamano
2011-09-23 9:00 ` Michael J Gruber
2011-09-23 9:47 ` Nguyen Thai Ngoc Duy
2011-09-23 19:04 ` Junio C Hamano
2011-09-25 5:21 ` Nguyen Thai Ngoc Duy
2011-09-22 22:09 ` [PATCH 4/6] request-pull: modernize style Junio C Hamano
2011-09-22 22:09 ` [PATCH 5/6] request-pull: state what commit to expect Junio C Hamano
2011-09-22 22:09 ` [PATCH 6/6] request-pull: use the branch description Junio C Hamano
2011-09-23 8:56 ` [PATCH 0/6] A handful of "branch description" patches Michael J Gruber
2011-09-23 20:18 ` Jeff King
2011-09-23 20:52 ` Junio C Hamano
2011-09-23 20:53 ` Jeff King
2011-09-24 14:42 ` Michael J Gruber
2011-09-27 21:58 ` Jeff King
2011-09-28 4:23 ` Annotated branch ≈ annotated tag? Michael Haggerty
2011-09-28 7:12 ` Andrew Ardill
2011-09-28 8:04 ` Michael Haggerty
2011-09-28 8:58 ` Branch annotations [Re: Annotated branch ≈ annotated tag?] Michael J Gruber
2011-09-29 6:44 ` Annotated branch ≈ annotated tag? Jeff King
2011-09-14 11:58 ` [Survey] Signed push Nguyen Thai Ngoc Duy
2011-09-14 21:05 ` Jonathan Nieder
2011-09-14 22:42 ` Nguyen Thai Ngoc Duy
2011-09-15 17:50 ` Jeff King
2011-09-14 19:35 ` Andy Lutomirski
2011-09-14 20:40 ` Junio C Hamano
2011-09-14 20:49 ` Andrew Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vobynui8a.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=torvalds@linux-foundation$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox