Junio C Hamano writes:
> But the point is that we do not want such an overhead in core, as
> all of that is a useless waste of the cycle for a site that wants to
> store the push certificate away outside of the repository itself.
By this I do not mean that cert blobs shouldn't become part of the
Santiago Torres writes:
> - *if there is a hook* the blob is computed, but it is up to the
> hook itself to store it *somewhere*. This makes me feel like it's
> somewhat of a useless waste of computation if the hook is not
> meant to handle it anyway(which is just a post-rec
On Mon, Sep 18, 2017 at 7:22 AM, Santiago Torres wrote:
> Hello, everyone.
>
> Sorry for being late in this thread, I was making sure I didn't say
> anything outrageously wrong.
>
>> That's Stefan; I wouldn't have suggested any approach that uses the
>> blob whose sole purpose is to serve as a tem
Hello, everyone.
Sorry for being late in this thread, I was making sure I didn't say
anything outrageously wrong.
> That's Stefan; I wouldn't have suggested any approach that uses the
> blob whose sole purpose is to serve as a temporary storage area to
> pass the information to the hook as part
Shikher Verma writes:
> This might be a good starting point for a sample hook if we choose to go
> that way. As Junio suggested.
>> This would not deal with concurrency as it re-uses the
>> same worktree, but illustrates what I had in mind
>> for the git history of that special ref.
That's Stefa
On Thu, Sep 07, 2017 at 05:43:19PM +, Stefan Beller wrote:
> On Thu, Sep 7, 2017 at 2:11 AM, Shikher Verma wrote:
> > On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:
> >> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma
> >> wrote:
> >> > Currently, git only stores push certifica
On Thu, Sep 7, 2017 at 2:11 AM, Shikher Verma wrote:
> On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:
>> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
>> > Currently, git only stores push certificates if there is a receive hook
>> > present. This may violate the principle o
On Thu, Sep 7, 2017 at 12:08 AM, Shikher Verma wrote:
> Hey everyone,
>
> I felt like I should introduce myself since this is my first patch on
> the git mailing list (or any mailing list actually) :D
Welcome to the list. :)
> I am Shikher[1], currently in my 4th year undergrad at IIT Kanpur.
>
On Wed, Sep 06, 2017 at 02:31:49PM -0700, Stefan Beller wrote:
> On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
> > Currently, git only stores push certificates if there is a receive hook
> > present. This may violate the principle of least surprise (e.g., I
> > pushed with --signed, and
On Thu, Sep 07, 2017 at 09:55:25AM +0900, Junio C Hamano wrote:
> Stefan Beller 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
Hey everyone,
I felt like I should introduce myself since this is my first patch on
the git mailing list (or any mailing list actually) :D
I am Shikher[1], currently in my 4th year undergrad at IIT Kanpur.
This summer I was lucky enough to intern at NYU Secure Systems Lab[2]
mentored by Santiago.
Stefan Beller 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 mi
On Wed, Sep 6, 2017 at 2:39 AM, Shikher Verma wrote:
> Currently, git only stores push certificates if there is a receive hook
> present. This may violate the principle of least surprise (e.g., I
> pushed with --signed, and I don't see anything in upstream).
> Additionally, push certificates could
Currently, git only stores push certificates if there is a receive hook
present. This may violate the principle of least surprise (e.g., I
pushed with --signed, and I don't see anything in upstream).
Additionally, push certificates could be more versatile if they are not
tightly bound to git ho
14 matches
Mail list logo