On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote:
> Dennis Kaarsemaker writes:
>
> > By not clearing the request buffer in stateless-rpc mode, fetch-pack
> > would keep sending already known-common commits, leading to ever bigger
> > http requests, eventually getting too large for git-http-
Junio C Hamano schrieb am 21.10.2014 um 20:14:
> Michael J Gruber writes:
>
>> Unfortunately, the git archive doc clearly says that the umask is
>> applied to all archive entries.
>
> Is an extended pax header "an archive entry"? I doubt it, and the
> above is not relevant. The mode bits for t
On Wed, Oct 22, 2014 at 2:41 PM, Dennis Kaarsemaker
wrote:
> I see two options:
>
> * Turning that interaction into a more cooperative process, with a
> select/poll loop
> * Make upload-pack buffer its entire response when run in stateless_rpc
> mode until it has consumed all of the request
O
push --signed promises to take user.signingkey as the signing key but
fails to read the config.
Make it do so.
Signed-off-by: Michael J Gruber
---
Interestingly, when I wrote the test I had the impression that user.email
is not heeded either - or do we have GIT_COMMITTER_EMAIL in the environment
push --signed promises to take user.signingkey as the signing key but
fails to read the config.
Make it do so.
Signed-off-by: Michael J Gruber
---
Okay, I guess this is nicer. We do have the committer info in the env. Sorry.
builtin/push.c | 13 -
t/lib-gpg/trustdb.gpg |
Dear Sir/Madam, Here is a pdf attachment of my proposal to you. Please
read and reply I would be grateful. Jose Calvache
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-
*ping*
Hope I didn't mess up formatting again...
Or do I need to top-post, as the original thread is too old to keep posting to
it?
Bernhard
Weitergeleitete Nachricht
Betreff: Re: [PATCH] git-imap-send: use libcurl for implementation
Datum: Sun, 12 Oct 2014 17:22:20 +0200
Von:
This is a first shot at documenting the various signatures that we use
in a technical document. If something like this is deemed useful
I should probably recreate the sample signatures using our testlib
keys and users in a v2.
Michael J Gruber (2):
Documentation/technical: signature formats
Do
Signed-off-by: Michael J Gruber
---
Documentation/technical/signature-format.txt | 35
1 file changed, 35 insertions(+)
diff --git a/Documentation/technical/signature-format.txt
b/Documentation/technical/signature-format.txt
index 80f0a47..49c2c82 100644
--- a/Docum
Various formats for storing signatures have accumulated by now.
Document them to keep track (and maybe avoid yet another one).
Signed-off-by: Michael J Gruber
---
Documentation/Makefile | 1 +
Documentation/technical/signature-format.txt | 126 +++
W dniu 2014-10-22 17:16, Michael J Gruber napisał:
+== Commit signature
+
+- created by: `git commit -s`
+- payload: commit object
+- embedding: header entry `gpgsig`
+ (content is preceded by a space)
+- example: commit with commit message `sigtest`
Actually it is not "content is preceded by
Dennis Kaarsemaker writes:
> On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote:
>> Dennis Kaarsemaker writes:
>>
>> > By not clearing the request buffer in stateless-rpc mode, fetch-pack
>> > would keep sending already known-common commits, leading to ever bigger
>> > http requests, eventu
--
On Tue, Oct 21, 2014 10:00 BST Eric Wong wrote:
>Jakob Stoklund Olesen wrote:
>> Yes, but I think you can remove cached_mergeinfo_rev too.
>
>Thanks, pushed the patch at the bottom, too.
>Also started working on some memory reductions here:
> http://mid.gmane.org/2
Bernhard Reiter writes:
> *ping*
> Hope I didn't mess up formatting again...
> Or do I need to top-post, as the original thread is too old to keep posting
> to it?
Please avoid top-posting on this list.
If you have some background material (e.g. summary of previous
discussions, list of things
Michael J Gruber writes:
> Various formats for storing signatures have accumulated by now.
> Document them to keep track (and maybe avoid yet another one).
I haven't looked at the description closely, but it is a good thing
to describe signature in a tag and in a commit in detail, which we
faile
Zoltan Klinger writes:
>> Junio C Hamano writes:
>>
>> It turns out that the result of such a change becomes more readable
>> than the original, in that it makes it clear that reinspection of
>> the lines are done only for matched ones and not context lines.
>>
>>
> Agree, it looks much clearer
Ronnie Sahlberg writes:
> commit fb5fa1d338ce113b0fea3bb955b50bbb3e827805 upstream.
Huh?
> Make the deletion of refs during a transaction more atomic.
> Start by first copying all loose refs we will be deleting to the packed
> refs file and then commit the packed refs file. Then re-lock the pac
I need to get a list of refs that can reach a certain SHA in in a script.
git branch --contains SHA
would be great (runs in ~2 seconds), but not my preferred option for scripting.
I tried
for br in $(git for-each-ref --format='%(refname:short)' refs/heads/)
do
git merge-base --is-ancestor
Stefan Beller writes:
> If you want me to continue using my gmail address, please check the
> authorship
> from the previous patch ([PATCH 1/2] transport: Free leaking head in
> transport_print_push_status)
> and remove the "From: Stefan Beller " line,
> so we don't end up needing this patch.
As
Michael J Gruber writes:
> push --signed promises to take user.signingkey as the signing key but
> fails to read the config.
>
> Make it do so.
>
> Signed-off-by: Michael J Gruber
> ---
> Okay, I guess this is nicer. We do have the committer info in the env. Sorry.
>
> builtin/push.c |
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> push --signed promises to take user.signingkey as the signing key but
>> fails to read the config.
>>
>> Make it do so.
>>
>> Signed-off-by: Michael J Gruber
>> ---
>> Okay, I guess this is nicer. We do have the committer info in the env. S
On Wed, Oct 22, 2014 at 11:42:48AM +0200, Michael J Gruber wrote:
> Junio C Hamano schrieb am 21.10.2014 um 20:14:
> > Michael J Gruber writes:
> >
> >> Unfortunately, the git archive doc clearly says that the umask is
> >> applied to all archive entries.
> >
> > Is an extended pax header "an ar
22 matches
Mail list logo
