git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v2 0/7] "push -s"
Date: Thu,  8 Sep 2011 13:01:35 -0700	[thread overview]
Message-ID: <1315512102-19022-1-git-send-email-gitster@pobox.com> (raw)

Slightly re-rolled from last night.

 - Marked push-certificate format as version 0 while we are
   still experimenting;
 - The push certificate records new object name and the refname;
 - Add support for an external hook "pre-receive-signature".

One issue internally debated was if we want to list the refs that matched
the pushing criteria but were found to be already up to date, and this can
be argued both ways.

 - You can say that you are making assertion that you want to have a
   certain object at that ref, in which case you would want to include
   them.

 - On the other hand, for the purpose of leaving audit-trail, if the ref
   you tried to push already had the object you wanted to see at the tip
   of a ref, you weren't the person who made the ref point at the object,
   and it would be sensible not to include them.

Taking the latter stance is slightly easier on the end users, because
"Everything up-to-date" case becomes a no-op as the natural consequence,
and we do not have to ask them to unlock their GPG key in such a case.  It
however makes it impossible to say "Earlier I pushed that object to the
tip of my branch but forgot to sign the push, and I want to make a signed
push, even though I didn't add anything to my history."

People who configured to push out more than one branches with "git push"
often work on one branch, run "git push" which ends up pushing that branch
but not other branches, then work on another branch and run "git push" to
push out that other branch, while the branch he earlier pushed out stays
the same since his last push. For such people, the first "push" is not
necessarily even an assertion that he wants to have both branches pointing
at certain commits, and from that point of view, not including the latter
branch he hasn't worked on (and stayed up-to-date) in the push certifiate
is a sensible thing to do.

As there is no single right answer, this round of re-roll keeps the latter
semantics to record only what you pushed out as the original series.

Junio C Hamano (7):
  send-pack: typofix error message
  Split GPG interface into its own helper library
  push -s: skeleton
  push -s: send signed push certificate
  push -s: receiving end
  refactor run_receive_hook()
  push -s: support pre-receive-signature hook

 Makefile               |    2 +
 builtin/push.c         |    1 +
 builtin/receive-pack.c |  206 +++++++++++++++++++++++++++++++++++++++++++-----
 builtin/send-pack.c    |   61 +++++++++++++-
 builtin/tag.c          |   60 ++------------
 builtin/verify-tag.c   |   35 +--------
 gpg-interface.c        |   94 ++++++++++++++++++++++
 gpg-interface.h        |   11 +++
 send-pack.h            |    1 +
 transport.c            |    4 +
 transport.h            |    4 +
 11 files changed, 369 insertions(+), 110 deletions(-)
 create mode 100644 gpg-interface.c
 create mode 100644 gpg-interface.h

-- 
1.7.7.rc0.188.g3793ac

             reply	other threads:[~2011-09-08 22:57 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-08 20:01 Junio C Hamano [this message]
2011-09-08 20:01 ` [PATCH v2 1/7] send-pack: typofix error message Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 2/7] Split GPG interface into its own helper library Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 3/7] push -s: skeleton Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 4/7] push -s: send signed push certificate Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 5/7] push -s: receiving end Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 6/7] refactor run_receive_hook() Junio C Hamano
2011-09-08 20:01 ` [PATCH v2 7/7] push -s: support pre-receive-signature hook Junio C Hamano
2011-09-09 20:41 ` [PATCH v3 0/4] Signed push Junio C Hamano
2011-09-09 20:41   ` [PATCH v3 1/4] send-pack: typofix error message Junio C Hamano
2011-09-09 20:41   ` [PATCH v3 2/4] Split GPG interface into its own helper library Junio C Hamano
2011-09-09 20:41   ` [PATCH v3 3/4] rename "match_refs()" to "match_push_refs()" Junio C Hamano
2011-09-09 20:41   ` [PATCH v3 4/4] push -s: signed push Junio C Hamano
2011-09-09 21:16     ` [PATCH v3.1 " Junio C Hamano
2011-09-10  5:19   ` [PATCH v3 0/4] Signed push Junio C Hamano
2011-09-10 15:17     ` Sverre Rabbelier
2011-09-10 16:30       ` Junio C Hamano
2011-09-10 19:22         ` Ted Ts'o
2011-09-11  1:42           ` Junio C Hamano
2011-09-11  8:53             ` Sverre Rabbelier
2011-09-11 15:51             ` Ted Ts'o
2011-09-10 20:05         ` Robin H. Johnson

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=1315512102-19022-1-git-send-email-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).