All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Shikher Verma <root@shikherverma.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	Santiago Torres <santiago@nyu.edu>
Subject: Re: [RFC PATCH 0/2] Add named reference to latest push cert
Date: Thu, 07 Sep 2017 09:55:25 +0900	[thread overview]
Message-ID: <xmqq4lsf2upu.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: CAGZ79kbxDh11KxrKCk_VjmN06kzp7x4iVO6XTV=a-qBmm39K5A@mail.gmail.com

Stefan Beller <sbeller@google.com> writes:

> On the ref to store the push certs:
> (a) Currently the ref points at the blob, I wonder if we'd rather want to
>     point at a commit? (Then we can build up a history of
>     push certs, instead of relying on the reflog to show all
>     push certs. Also the gc issue might be easier to solve using this)
> (b) When going with (a), we might want to change the name. Most
>     refs are 3 directories deep:
>       refs/heads/<branch name>
>       refs/pr/<pull request nr> # at github IIUC
>       refs/changes/<id> # Gerrit
>       refs/meta/config # Gerrit to e.g. configure ACLs of the repo
>     "refs" indicates it is a ref, whereas the second part can be seen
>     as a "namespace". Currently Git only uses the "heads" and "tags"
>     namespace, "meta" is used by more than just Gerrit, so maybe it is
>     not wise to use "refs/meta/push_cert", but go with refs/gitmeta/pushcert
>     instead?

You also need to worry about concurrent pushes.  The resulting
"history" may not have to be sequencial, but two pushes that affect
the same ref must be serialized in the resulting push-cert store.

The original design deliberately punts all the complexity to hook
exactly because we do not want to have a half-baked "built-in"
implementation that would only get in the way of those who wants to
do high-performance servers.  It is very likely that they want to
have a long-running daemon that listens to a port or a named pipe,
where the only thing the hook would do is to write the value of
GIT_PUSH_CERT to that daemon process, which acts as a serialization
point, can read from the object store that is used as a short-term
temporary area, and write the push cert to a more permanent store.

Having said all that, I am sympathetic to a wish to have an
easy-to-enable-without-thinking example that is not so involved
(e.g. no portability concern, does not have to perform very well but
must be correct).  If Shikher wants to add one, I think the right
approach to do so would be to add and ship a sample hook.

Thanks.

  reply	other threads:[~2017-09-07  0:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20170906093913.21485-1-root@shikherverma.com>
2017-09-06 21:31 ` [RFC PATCH 0/2] Add named reference to latest push cert Stefan Beller
2017-09-07  0:55   ` Junio C Hamano [this message]
2017-09-07  8:55     ` Shikher Verma
2017-09-07  9:11   ` Shikher Verma
2017-09-07 17:43     ` Stefan Beller
2017-09-16  7:21       ` Shikher Verma
2017-09-17  1:40         ` Junio C Hamano
2017-09-18 14:22           ` Santiago Torres
2017-09-18 17:43             ` Stefan Beller
2017-09-19  1:04             ` Junio C Hamano
2017-09-19  3:11               ` Junio C Hamano
2017-12-02  9:12                 ` [PATCH] Add a sample hook which saves push certs as notes Shikher Verma
2017-12-03  0:45                   ` Todd Zullinger
2017-12-03  6:05                     ` Junio C Hamano
2017-09-07  7:08 ` [RFC PATCH 0/2] Add named reference to latest push cert Shikher Verma
2017-09-07 17:21   ` Stefan Beller

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=xmqq4lsf2upu.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=root@shikherverma.com \
    --cc=santiago@nyu.edu \
    --cc=sbeller@google.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.