Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
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-backend to > > handle properly without filling up the pipe buffer in inflate_request. > > --- > > I'm still not quite sure whether this is the right thing to do, but make > > test still passes :) The new testcase demonstrates the problem, when > > running t5551 with EXPENSIVE, this test will hang without the patch to > > fetch-pack.c and succeed otherwise. > > IIUC, because "stateless" is just that, i.e. the server-end does not > keep track of what is already known, not telling what is known to be > common in each request would fundamentally break the protocol. Am I > mistaken? That sounds plausible, but why then does the fetch complete with this line removed, and why does 'make test' still pass? I tried to understand the protocol, but the documentation has TODO's in some critical places :) And if that's true, it means the inflate_request / upload-pack interaction should be fixed, so more than 64k (current linux pipe buffer size) of uncompressed data is supported. 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 The latter sounds easier to do, but not being very familiar with the protocol, I may have missed something obvious. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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-info.html
Re: Sources for 3.18-rc1 not uploaded
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 the archive entry that it > applies to does not come from there. The problem seem to be old tar versions which mis-take the extensions for archive entries, aren't they? > See my other message for my final judgement on this one. I wouldn't > have minded if the original used the same umask for those ignored > mode bits, but changing the bits to be ignored after the fact is not > helping any real use case and only hurts existing users. > > That is not to say that we cannot later fix bigger issues in the > output. I just do not see that otherwise-unused mode bits in the > extended pax header big enough an issue to spend brain cycles to > carefully lay and execute transition plans to avoid breaking > existing users. My question to Brian still stands which existing users he was trying to cater for with his patch. If there indeed are no existing affected users besides the KUP users (as you seem to assume) it's a clear case. Pun intended ;) As I pointed out (and you cut out), I don't mind doing the revert. I just want us to do the right things for the right reasons (the ones you ponted out, Junio). Michael -- 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-info.html
Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
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 Or add a helper daemon and support stateful smart http. Or maybe that's what you meant in the first option. -- Duy -- 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-info.html
[RFD/PATCH] push: heed user.signingkey for signed pushes
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
of the tests by default?
In any case, that is why the test looks the way it looks and why this is RFD.
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/builtin/push.c b/builtin/push.c
index ae56f73..a076b19 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -471,6 +471,17 @@ static int option_parse_recurse_submodules(const struct
option *opt,
return 0;
}
+static int git_push_config(const char *k, const char *v, void *cb)
+{
+ struct wt_status *s = cb;
+ int status;
+
+ status = git_gpg_config(k, v, NULL);
+ if (status)
+ return status;
+ return git_default_config(k, v, s);
+}
+
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
@@ -511,7 +522,7 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
};
packet_trace_identity("push");
- git_config(git_default_config, NULL);
+ git_config(git_push_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL |
TRANSPORT_PUSH_MIRROR
--
2.1.2.756.gfa53a0a
builtin/push.c | 13 -
t/lib-gpg/trustdb.gpg | Bin 1360 -> 1360 bytes
t/t5534-push-signed.sh | 43 +++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/builtin/push.c b/builtin/push.c
index ae56f73..a076b19 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -471,6 +471,17 @@ static int option_parse_recurse_submodules(const struct
option *opt,
return 0;
}
+static int git_push_config(const char *k, const char *v, void *cb)
+{
+ struct wt_status *s = cb;
+ int status;
+
+ status = git_gpg_config(k, v, NULL);
+ if (status)
+ return status;
+ return git_default_config(k, v, s);
+}
+
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
@@ -511,7 +522,7 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
};
packet_trace_identity("push");
- git_config(git_default_config, NULL);
+ git_config(git_push_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL |
TRANSPORT_PUSH_MIRROR
diff --git a/t/lib-gpg/trustdb.gpg b/t/lib-gpg/trustdb.gpg
index
4879ae9a84650a93a4d15bd6560c5d1b89eb4c2f..c11b1464b3d13b45966a493e2174fc0e253ddd0c
100644
GIT binary patch
delta 47
ncmcb>b%9HOF})z2nVFH5k%@sJ#C^}~iH71E)x}wb7%%_;=xPS!
delta 51
tcmcb>b%9HSF})z2nVFH5k%@sJ&}Z5*1_lPkiGso#)x}wb*nk{V008$D2C@JE
diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh
index 2786346..c68867d 100755
--- a/t/t5534-push-signed.sh
+++ b/t/t5534-push-signed.sh
@@ -124,4 +124,47 @@ test_expect_success GPG 'signed push sends push
certificate' '
test_cmp expect dst/push-cert-status
'
+test_expect_success GPG 'fail without key and heed user.signingkey' '
+ prepare_dst &&
+ mkdir -p dst/.git/hooks &&
+ git -C dst config receive.certnonceseed sekrit &&
+ write_script dst/.git/hooks/post-receive <<-\EOF &&
+ # discard the update list
+ cat >/dev/null
+ # record the push certificate
+ if test -n "${GIT_PUSH_CERT-}"
+ then
+ git cat-file blob $GIT_PUSH_CERT >../push-cert
+ fi &&
+
+ cat >../push-cert-status <
+ KEY=13B6F51ECDDE430D
+ STATUS=G
+ NONCE_STATUS=OK
+ EOF
+ sed -n -e "s/^nonce /NONCE=/p" -e "/^$/q" dst/push-cert
+ ) >expect &&
+
+ grep "$(git rev-parse noop ff) refs/heads/ff" dst/push-cert &&
+ grep "$(git rev-parse noop noff) refs/heads/noff" dst/push-cert &&
+ test_cmp expect dst/push-cert-status
+'
+
test_done
--
2.1.2.756.gfa53a0a
--
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-info.html
[PATCHv2] push: heed user.signingkey for signed pushes
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 | Bin 1360 -> 1360 bytes
t/t5534-push-signed.sh | 44
3 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/builtin/push.c b/builtin/push.c
index ae56f73..a076b19 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -471,6 +471,17 @@ static int option_parse_recurse_submodules(const struct
option *opt,
return 0;
}
+static int git_push_config(const char *k, const char *v, void *cb)
+{
+ struct wt_status *s = cb;
+ int status;
+
+ status = git_gpg_config(k, v, NULL);
+ if (status)
+ return status;
+ return git_default_config(k, v, s);
+}
+
int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
@@ -511,7 +522,7 @@ int cmd_push(int argc, const char **argv, const char
*prefix)
};
packet_trace_identity("push");
- git_config(git_default_config, NULL);
+ git_config(git_push_config, NULL);
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL |
TRANSPORT_PUSH_MIRROR
diff --git a/t/lib-gpg/trustdb.gpg b/t/lib-gpg/trustdb.gpg
index
4879ae9a84650a93a4d15bd6560c5d1b89eb4c2f..c11b1464b3d13b45966a493e2174fc0e253ddd0c
100644
GIT binary patch
delta 47
ncmcb>b%9HOF})z2nVFH5k%@sJ#C^}~iH71E)x}wb7%%_;=xPS!
delta 51
tcmcb>b%9HSF})z2nVFH5k%@sJ&}Z5*1_lPkiGso#)x}wb*nk{V008$D2C@JE
diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh
index 2786346..ecb8d44 100755
--- a/t/t5534-push-signed.sh
+++ b/t/t5534-push-signed.sh
@@ -124,4 +124,48 @@ test_expect_success GPG 'signed push sends push
certificate' '
test_cmp expect dst/push-cert-status
'
+test_expect_success GPG 'fail without key and heed user.signingkey' '
+ prepare_dst &&
+ mkdir -p dst/.git/hooks &&
+ git -C dst config receive.certnonceseed sekrit &&
+ write_script dst/.git/hooks/post-receive <<-\EOF &&
+ # discard the update list
+ cat >/dev/null
+ # record the push certificate
+ if test -n "${GIT_PUSH_CERT-}"
+ then
+ git cat-file blob $GIT_PUSH_CERT >../push-cert
+ fi &&
+
+ cat >../push-cert-status <
+ KEY=13B6F51ECDDE430D
+ STATUS=G
+ NONCE_STATUS=OK
+ EOF
+ sed -n -e "s/^nonce /NONCE=/p" -e "/^$/q" dst/push-cert
+ ) >expect &&
+
+ grep "$(git rev-parse noop ff) refs/heads/ff" dst/push-cert &&
+ grep "$(git rev-parse noop noff) refs/heads/noff" dst/push-cert &&
+ test_cmp expect dst/push-cert-status
+'
+
test_done
--
2.1.2.756.gfa53a0a
--
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-info.html
Please reply
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-info.html
Fwd: Re: [PATCH] git-imap-send: use libcurl for implementation
*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: Bernhard Reiter An: Junio C Hamano Kopie (CC): git@vger.kernel.org, Jonathan Nieder , Jeff King , 434...@bugs.debian.org, René Scharfe , Tony Finch , Tanay Abhra , Dan Albert , Jeremy Huddleston , David Aguilar , Michael Haggerty , Oswald Buddenhagen Sorry for not getting back to this any sooner, I've been pretty busy recently with Other Projects(tm). Am 2014-08-27 um 19:20 schrieb Junio C Hamano: > Bernhard Reiter writes: > >> [...] For now, >> the old ones are wrapped in #ifdefs, and the new functions are enabled >> by make if curl's version is >= 7.35.0, from which version on curl's >> CURLOPT_LOGIN_OPTIONS (enabling IMAP authentication) parameter has been >> available. > > https://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions > says that this was introduced as of 7.34.0, though. Strange, I thought I recalled having seen that in http://curl.haxx.se/libcurl/c/CURLOPT_LOGIN_OPTIONS.html but it clearly says 7.34.0 there too. I've now changed all occurrences of 7.35.0 to 7.34.0 (and the corresponding hex value in the Makefile). >> As I don't have access to that many IMAP servers, I haven't been able to >> test the new code with a wide variety of parameter combinations. I did >> test both secure and insecure (imaps:// and imap://) connections and >> values of "PLAIN" and "LOGIN" for the authMethod. > > Perhaps CC'ing those who have touched git-imap-send code over the > years and asking for their help testing might help? CC'ing them (going back about 2 years, which already makes the list quite long) and the people who have taken part in the initial discussion on this feature in August. And the related Debian bug. Please test this, folks! >> Signed-off-by: Bernhard Reiter >> --- >> I rebased the patch on the pu branch, hope that was the right thing to do. > > Usually I would appreciate a patch for a new feature not meant for > the maintenance tracks to be based on 'master', so that it can go to > the next release without having to wait other changes that may > conflict with it and that may not yet be ready. > > I will try to apply this one to 'pu', rebase it on 'master' to make > sure the result does not depend on the other topics in flight, and > then merge it back to 'pu'. Okay, I'll stick to master. I've rebased on master now that the first couple related patches are there anyway. > [...] >> >> diff --git a/Documentation/git-imap-send.txt >> b/Documentation/git-imap-send.txt >> index 7d991d9..9d244c4 100644 >> --- a/Documentation/git-imap-send.txt >> +++ b/Documentation/git-imap-send.txt >> @@ -75,7 +75,8 @@ imap.preformattedHTML:: >> >> imap.authMethod:: >> Specify authenticate method for authentication with IMAP server. >> -Current supported method is 'CRAM-MD5' only. If this is not set >> +If you compiled git with the NO_CURL option or if your curl version is >> +< 7.35.0, the only supported method is 'CRAM-MD5'. If this is not set >> then 'git imap-send' uses the basic IMAP plaintext LOGIN command. > > Hmph, so there is no option that lets me say "I know my libcurl is > new enough but I have some reason not to want to use the new code to > interact with my imap server", at compile time or (more preferrably) > at runtime? Added a runtime option, see below. >> diff --git a/INSTALL b/INSTALL >> index 6ec7a24..e2770a0 100644 >> --- a/INSTALL >> +++ b/INSTALL >> @@ -108,18 +108,21 @@ Issues of note: >>so you might need to install additional packages other than Perl >>itself, e.g. Time::HiRes. >> >> -- "openssl" library is used by git-imap-send to use IMAP over SSL. >> - If you don't need it, use NO_OPENSSL. >> +- "openssl" library is used by git-imap-send to use IMAP over SSL, >> + unless you're using curl >= 7.35.0, in which case that will be >> + used. If you don't need git-imap-send, you can use NO_OPENSSL. > > The last sentence makes it unclear which of the following is true: > > - I have sufficiently new libcurl. I cannot say NO_OPENSSL because >I do need git-imap-send. > > - I have sufficiently new libcurl, so "openssl" is not used by >git-imap send for me. I can say NO_OPENSSL. > > Perhaps > > - git-imap-send needs the OpenSSL library to talk IMAP over SSL if >you are using libCurl older than 7.35.0. Otherwise you can use >NO_OPENSSL without losing git-imap-send. Fixed. >> diff --git a/git.spec.in b/git.spec.in >> index d61d537..9535cc3 100644 >> --- a/git.spec.in >> +++ b/git.spec.in >> @@ -8,7 +8,7 @@ License: GPL >> Group: Development/Tools >> URL:http://kernel.org/pub/software/scm/git/ >> Source: http://kernel.org/pub/soft
[PATCH 0/2] document signature formats
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 Documentation/technical: document push certificate format Documentation/Makefile | 1 + Documentation/technical/signature-format.txt | 161 +++ 2 files changed, 162 insertions(+) create mode 100644 Documentation/technical/signature-format.txt -- 2.1.2.756.gfa53a0a -- 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-info.html
[PATCH 2/2] Documentation/technical: document push certificate format
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/Documentation/technical/signature-format.txt +++ b/Documentation/technical/signature-format.txt @@ -124,3 +124,38 @@ tagmess Conflicts: ... + +== Push certificate + +- created by: `git push --signed` +- payload: a push certificate header followed by the push transcript + (see pack-protocol.txt) +- embedding: append the signature to the push transcript +- example: push of commit `21723` updating `master` on `localhost` + from `45cfe` + + +certificate version 0.1 +pusher Michael J Gruber 1413979846 +0200 +pushee localhost:/tmp/t/a +nonce 1413979846-48813c0bc9d3b598d71d + +45cfec8735b7842a32dcc092a14850aa6220ef33 217230e5793407fc7c099117011ed13143fece63 refs/heads/master +-BEGIN PGP SIGNATURE- +Version: GnuPG v1 + +iQIcBAABCgAGBQJUR57GAAoJELR76rQkz552EWMP/3yHaFYuG3T/FcshgXQubsml +t4TvkegjQFtVK31oedqaAQGJYusXX2/yUFviXpRq611Aj7rooBnpZYZKT5lUm/ol +m9KjDvFpOiY7rA/y6BBetSX6s6uhmO4WcgJ4hSsMZ4z+001y2zawxWm0cedurIcO +hpKbAmQ/EiMmQiA4D9vKmLJUXpzF63NzMElZfWzHLa0IU1ZN6EvH1l+N7ulBNsuv +lTh3UxjabJr4vpu6kwMquCGqRB60+rdG7itiHwRQynnmDhvXoQxtU9gtLymXKJIS +SGQ5v3B5hsGA2LkCCkvNj+QRLH9LF8iAZqezqGA5U/Cg7xckOPlMwFllTv8goDBW +IB7Mk5lpQqaUCZf33uIppiEtHipLpGI90NLCm+JvzrNnnseSS6jARVRMx6cWp+dB +9QTCq80mRI/zzcvDyPhNvj0tP3mUTFmR4+KRh+4zRq9iOGp5KpJrpFjndCQELwAW +402hXEEjB4Kq7KSU4jEoaYGrJR9KJmPmgWHvz2GaJZ5eCJIXuoLGZo3TtxXRHB9p +EqWp3iZOZotxZmUVHgohFhqxZgcAefdfzZUqQ8jY3hHvu5Zwd2muToc8Nh/vIHoB +us0NHUiI8TOccAHd8AIrqgoXj2gChr3cQxWNcfBfx+ALT8sEtNrVkkrovmRiMEa4 +MxEdQTwhooEE8PWD5Yj5 +=6MAR +-END PGP SIGNATURE- + -- 2.1.2.756.gfa53a0a -- 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-info.html
[PATCH 1/2] Documentation/technical: signature formats
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 +++ 2 files changed, 127 insertions(+) create mode 100644 Documentation/technical/signature-format.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index cea0e7a..2638c0c 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -74,6 +74,7 @@ TECH_DOCS += technical/protocol-common TECH_DOCS += technical/racy-git TECH_DOCS += technical/send-pack-pipeline TECH_DOCS += technical/shallow +TECH_DOCS += technical/signature-format TECH_DOCS += technical/trivial-merge SP_ARTICLES += $(TECH_DOCS) SP_ARTICLES += technical/api-index diff --git a/Documentation/technical/signature-format.txt b/Documentation/technical/signature-format.txt new file mode 100644 index 000..80f0a47 --- /dev/null +++ b/Documentation/technical/signature-format.txt @@ -0,0 +1,126 @@ +Git signature format + + +== Overview + +Git uses cryptographic signatures in various places, currently +objects (tags, commits, mergetags) and transactions (pushes). +In every case, the command which is about to create an object or +transaction determines a payload from that, calls gpg to obtain +a detached signature for the payload and embeds the signature +into the object or transaction. + +Signatures always begin with `-BEGIN PGP SIGNATURE-` +and end with `-END PGP SIGNATURE-`. + +== Tag signatures + +- created by: `git tag -s` +- payload: annotated tag object +- embedding: append the signature to the tag object +- example: tag `stag` with tag message `tagmess` + + +object 8cbad082a020b7d4ef729b14e1a654c4f60791c6 +type commit +tag stag +tagger Michael J Gruber 1351067460 +0200 + +tagmess +-BEGIN PGP SIGNATURE- +Version: GnuPG v1.4.12 (GNU/Linux) + +iQIcBAABCgAGBQJQh6dPAAoJELR76rQkz552ZBEP/3vkpftZnhsUkGhqXXptnRhz +5A3n+BqFTsh4d4C15lcRcevwTyyQF61vrFKFRE7Cl5XVqVHowW0al+Dx7j5p35Mz +PqBZUbEkBFc9xY8WasQYbJl5yDboc8Ora71SEJ1k59duETXmZ67ISpEe6HF3d2xK +3BGfqaBMwU+Aql0pDMtysoOgEgs7d/Vin9gIXJcqAvw71bpNyZvFUln3do2eLC/v +VW0bVvAN3B66fLx3li8hEZ4wfrg0Uui5zSN95+uc2DUGW03BNR/sKhYXstHAoqef +4WIAD70e+9vArh8WqPTIUWl0w+1ixgVvGckHXHW10MdwkoVtwo4tawRxngLBKuI9 +pUu7dc/TIVl15z/y1EmQ25rB4WV9M9W+uRauUi/T3c0hfSuZkB6B1tCu3QStPbWz +AK3O6Neoni2NgMDLmrWzgDZA3Z/+h9RBV/kNda0RpbWZYJOJILBR+Q8+BZOwDZX/ +hu/tITC7IHVJgMXYGlEFybEn/clbtLsZr8zLlSZyropl0mvUBLeBCrjYBQuDN86g +yew/Tzs9T5MEFagUkbRERz5rP5OIE9XpXcHMsZve7cCL3YQy0LOkZk3RZKUsbv8g +MVU1px5/ImBkr0MU0XZxstsAV0YPiON3+qMOnrdGuFx11YQi6cmIA2eww2KPqzHY +YKirAGNintaD8yXAlwLd +=wF8p +-END PGP SIGNATURE- + + +== 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` + + +tree 14461762125c079e55a9684ae3a96e27de5b3f2f +parent da19995926ec89e48297a3163b0f5190af3a8650 +author Michael J Gruber 1325088101 +0100 +committer Michael J Gruber 1325088101 +0100 +gpgsig -BEGIN PGP SIGNATURE- + Version: GnuPG v1.4.11 (GNU/Linux) + + iQIcBAABCgAGBQJO+z1lAAoJELR76rQkz552xOoQAJgV6sstR8cge760X7awb00V + svN+pcc1TtJZecYWakCIe6dGPAK2Yk1AwExV0tbAQskPxYIqwnuysXHvVlmyJh5P + 1N033YSRc8j59YNQNaLIAh6+c59cKcZdWQyrA1HFVWGqoafCD2+nMglb/JbN9jqQ + 5gsxfFGoE0blT+BnMrchzPL4kjMJQBszV5ccATu3iIgSv23p5rA4tm3/P44enIsH + U9nYODlKmzsAulThQoSd4Qk0MNIg86MjIXanPkj4S+TLLgDa6Zf8W3m28IiRwPF1 + WemWpQ9VwSSHKuGVyHGG2OErtDDftILcYtjW5c/UnLw38hWPwc+KxVmAdEBY3vgk + OACDEDLqAWgc4rLdWgkoxieIi0aKN+iN4kogbEtSl4VzgvX0iGLZP8cyJnGxHria + Qz2UcesNqVPPqOxsIJKpr3CByrh2WDzH8W3tvGuy5q8EsTx5uF1HGoYb3PIx76QG + 3ClhL5Wtjk3/iQnycWo60eKMJccLbv+uoXzUP3LA0prt0K3a+52pWVppt8RW1L6u + kALJjsc44gr04v/fo5x6zkgFFt+8e/YWDZO+vwCJDmCyqggEvA5dj6i0y2B+hZjL + RVG0RATLroPgMa6oHSEVEbP+Ui4JZ3k3fRLIOupb0qjHtv/cvB7kcXevpdQUFGs0 + 6kmaMJBcWutA6HrosuP/ + =9PhX + -END PGP SIGNATURE- + +sigtest + + +== Mergetag signature + +- created by: `git merge` on signed tag +- payload/embedding: the whole signed tag object is embedded into + the (merge) commit object of header entry `mergetag` +- example: merge of the signed tag `stag` as above + + +tree ceb2177fea91ec9369e012dbe794419ee0731ce7 +parent 9c20ba82367dab0fe4789e2be400a7fb0c447c34 +parent 8cbad082a020b7d4ef729b14e1a654c4f60791c6 +author Michael J Gruber 1412951117 +0200 +committer Michael J Gruber 1412951117 +0200 +mergetag object 8cbad082a020b7d4ef729b14e1a654c4f60791c6 + type commit + tag stag + tagger Michael J Gruber 1351067460 +0200 + + tagmess + -BEGIN PGP SIGNATURE- + Version: GnuPG v1.4.12 (GNU/Linux) + + iQIcBAABCgAGBQJQh6dPAAoJELR76rQkz552ZBEP/3vkpftZnhsUkGhqXXptnRhz + 5A3n+BqFTsh4d4C15lcRcevwTyyQF61vrFKFRE7Cl5XVqVHowW0al+Dx7j5p35Mz + PqBZUbEkBFc9xY8WasQYbJl5yDboc8Ora71SEJ1k59duETXmZ67ISpEe6HF3d2xK + 3BGfqaBMwU+Aql
Re: [PATCH 1/2] Documentation/technical: signature formats
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 space", but it is multi-line header which uses RFC-2822 like wrapping (see "Long Header Fields" there) - leading space means wrapped in email, separate line here. Nice work. -- Jakub Narębski -- 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-info.html
Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
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, eventually getting too large for git-http-backend to >> > handle properly without filling up the pipe buffer in inflate_request. >> > --- >> > I'm still not quite sure whether this is the right thing to do, but make >> > test still passes :) The new testcase demonstrates the problem, when >> > running t5551 with EXPENSIVE, this test will hang without the patch to >> > fetch-pack.c and succeed otherwise. >> >> IIUC, because "stateless" is just that, i.e. the server-end does not >> keep track of what is already known, not telling what is known to be >> common in each request would fundamentally break the protocol. Am I >> mistaken? > > That sounds plausible, but why then does the fetch complete with this > line removed, and why does 'make test' still pass? The fetch-pack program tries to help the upload-pack program(s) running on the other end find what nodes in the graph both repositories have in common by sending what the repository on its end has. Some commits may not be known by the other side (e.g. your new commits that haven't been pushed there that are made on a branch forked from the common history), and some others may be known (i.e. you drilled down the history from the tips of your refs and reached a commit that you fetched from the common history previously). The latter are ACKed by the upload-pack process and are remembered to be re-sent to the _next_ incarnation of the upload-pack process when stateless RPC is in use. With your patch, you stop telling the upload-pack process what these two programs already found to be common in their exchange. After the first exchange, fetch-pack and upload-pack may have noticed that both ends have version 2.0, but because you do not convey that fact to the other side, the new incarnation of upload-pack may end up deciding that the version 1.9 is the newest common commit between the two, and sending commits between 1.9 and 2.0. If you imagine an extreme case, it would be easy to see why "the fetch completes" and "make test passes" are not sufficient to say anything about this change. Even if you break the protocol in in a way different from your patch, by not sending any "have", such a butchered "fetch-pack" will become "fetch everything from scratch", aka "clone". The end result will still have correct history and "fetch completes" would be true. But I'd prefer deferring a more detailed analysis/explanation to Shawn, as stateless RPC is his creation. -- 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-info.html
Re: git-svn performance
--
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/20141021033912.ga27...@dcvr.yhbt.net
>But there seem to be more problems :<
>
>8<-
>From: Eric Wong
>Date: Tue, 21 Oct 2014 06:23:22 +
>Subject: [PATCH] git-svn: remove mergeinfo rev caching
>
>This should further reduce memory usage from the new mergeinfo
>speedups without hurting performance too much, assuming
>reasonable latency to the SVN server.
>
>Cc: Hin-Tak Leung
>Suggested-by: Jakob Stoklund Olesen
>Signed-off-by: Eric Wong
>---
> perl/Git/SVN.pm | 30 +-
> 1 file changed, 9 insertions(+), 21 deletions(-)
>
>diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
>index f8a75b1..4364506 100644
>--- a/perl/Git/SVN.pm
>+++ b/perl/Git/SVN.pm
>@@ -1710,32 +1710,20 @@ sub mergeinfo_changes {
> my %minfo = map {split ":", $_ } split "\n", $mergeinfo_prop;
> my $old_minfo = {};
>
>- # Initialize cache on the first call.
>- unless (defined $self->{cached_mergeinfo_rev}) {
>- $self->{cached_mergeinfo_rev} = {};
>- }
>-
>- my $cached_rev = $self->{cached_mergeinfo_rev}{$old_path};
>- unless (defined $cached_rev && $cached_rev == $old_rev) {
>- my $ra = $self->ra;
>- # Give up if $old_path isn't in the repo.
>- # This is probably a merge on a subtree.
>- if ($ra->check_path($old_path, $old_rev) != $SVN::Node::dir) {
>- warn "W: ignoring svn:mergeinfo on $old_path, ",
>- "directory didn't exist in r$old_rev\n";
>- return {};
>- }
>- }
>- my (undef, undef, $props) = $self->ra->get_dir($old_path, $old_rev);
>+ my $ra = $self->ra;
>+ # Give up if $old_path isn't in the repo.
>+ # This is probably a merge on a subtree.
>+ if ($ra->check_path($old_path, $old_rev) != $SVN::Node::dir) {
>+ warn "W: ignoring svn:mergeinfo on $old_path, ",
>+ "directory didn't exist in r$old_rev\n";
>+ return {};
>+ }
>+ my (undef, undef, $props) = $ra->get_dir($old_path, $old_rev);
> if (defined $props->{"svn:mergeinfo"}) {
> my %omi = map {split ":", $_ } split "\n",
> $props->{"svn:mergeinfo"};
> $old_minfo = \%omi;
> }
>- $self->{cached_mergeinfo_rev}{$old_path} = $old_rev;
>-
>- # Cache the new mergeinfo.
>- $self->{cached_mergeinfo_rev}{$path} = $rev;
>
> my %changes = ();
> foreach my $p (keys %minfo) {
>--
>EW
I'll have a look at the new changes at some point - I am still keeping the old
clone and the new clone and just fetching from time to time to keep them
in sync. I just tried that and fetching the same 50 commits on the old clone
took 1.7 GB memory vs 1.0 GB memory on the new. Details below.
This is just with the 2 earliest patches - I'll put the new 3 in at some point.
So I see some needs for retrospectively fixing old clones (maybe as part
of garbage collection?), since most would simply use an old clone through
the ages...
Comparing trunk of old and new, I see one difference - One short
commit message is missing in the *old* (the "Add checkPoFiles etc." part)
and so all the sha1 afterwards differed. Is that an old bug that's fixed
and therefore I should throw away the old clone?
Date: Wed Apr 25 18:21:29 2012 +
Add checkPoFiles etc.
git-svn-id: https://svn.r-project.org/R/trunk@59188
Here is the details of fetching old and new:
<---
$ /usr/bin/time -v git svn fetch --all
M doc/manual/R-admin.texi
r66784 = fc20374f26f8e03bb88c00933982e29138a6f929 (refs/remotes/trunk)
...
M configure
r66834 = d8d1876f6aa71b3fe3773cd28a760ff945d30bdf (refs/remotes/R-3-1-branch)
Command being timed: "git svn fetch --all"
User time (seconds): 1520.77
System time (seconds): 156.32
Percent of CPU this job got: 98%
Elapsed (wall clock) time (h:mm:ss or m:ss): 28:15.82
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1738276
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 613
Minor (reclaiming a frame) page faults: 2039305
Voluntary context switches: 11243
Involuntary context switches: 181507
Swaps: 0
File system inputs: 658328
File system outputs: 754688
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
$ cd ../R-2/
[Hin-Tak@localhost R-2]$ /usr/bin/time -v git svn fetch --all
M doc/manual/R-admin.texi
r66784
Re: Fwd: Re: [PATCH] git-imap-send: use libcurl for implementation
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 that have been changed in response to previous review, etc.), you have three options: * Use a cover letter, even for a one-patch topic. Use [PATCH 0/1] for the background material if you have tons of it and then make [PATCH 1/1] as a follow-up to that cover letter. See http://thread.gmane.org/gmane.comp.version-control.git/256386 for how such an approach looks like. * Use a single message, [PATCH] (aka [PATCH 1/1]), and add your background material _after_ three-dash lines as comment. See http://thread.gmane.org/gmane.comp.version-control.git/258451 for how such an approach looks like. * Use a single message, [PATCH] (aka [PATCH 1/1]), and add your background material _before_ a scissors line "-- >8 --", optionally followed by "From:" and/or "Subject:" (but in your case, you are sending your own patch as yourself with the same subject, so neither of them apply). See http://thread.gmane.org/gmane.comp.version-control.git/258470/focus=258474 for how such an approach looks like. Thanks. -- 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-info.html
Re: [PATCH 1/2] Documentation/technical: signature formats
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 failed to do so far. The principle is essentially the same between the signature on a tag and on a commit: a detached PGP signature over the remainder of the object data is created, and then the signature is inserted into an appropriate place in the resulting object. That "appropriate place" is influenced by the type and nature of the object. A mergetag is not fundamentally a "signature" in the above sense, though. It is just a dump of the object content in a regular object header field (hence indented by one SP), and its contents having PGP SIGNATURE is merely a natural consequence of the object recorded being a signed tag. So the description of it in the same place as description for signed tags and signed commits feels a little bit out of place, but I do not think of a better place to describe it. Thanks. > Signed-off-by: Michael J Gruber > --- > Documentation/Makefile | 1 + > Documentation/technical/signature-format.txt | 126 > +++ > 2 files changed, 127 insertions(+) > create mode 100644 Documentation/technical/signature-format.txt > > diff --git a/Documentation/Makefile b/Documentation/Makefile > index cea0e7a..2638c0c 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefile > @@ -74,6 +74,7 @@ TECH_DOCS += technical/protocol-common > TECH_DOCS += technical/racy-git > TECH_DOCS += technical/send-pack-pipeline > TECH_DOCS += technical/shallow > +TECH_DOCS += technical/signature-format > TECH_DOCS += technical/trivial-merge > SP_ARTICLES += $(TECH_DOCS) > SP_ARTICLES += technical/api-index > diff --git a/Documentation/technical/signature-format.txt > b/Documentation/technical/signature-format.txt > new file mode 100644 > index 000..80f0a47 > --- /dev/null > +++ b/Documentation/technical/signature-format.txt > @@ -0,0 +1,126 @@ > +Git signature format > + > + > +== Overview > + > +Git uses cryptographic signatures in various places, currently > +objects (tags, commits, mergetags) and transactions (pushes). > +In every case, the command which is about to create an object or > +transaction determines a payload from that, calls gpg to obtain > +a detached signature for the payload and embeds the signature > +into the object or transaction. > + > +Signatures always begin with `-BEGIN PGP SIGNATURE-` > +and end with `-END PGP SIGNATURE-`. > + > +== Tag signatures > + > +- created by: `git tag -s` > +- payload: annotated tag object > +- embedding: append the signature to the tag object > +- example: tag `stag` with tag message `tagmess` > + > + > +object 8cbad082a020b7d4ef729b14e1a654c4f60791c6 > +type commit > +tag stag > +tagger Michael J Gruber 1351067460 +0200 > + > +tagmess > +-BEGIN PGP SIGNATURE- > +Version: GnuPG v1.4.12 (GNU/Linux) > + > +iQIcBAABCgAGBQJQh6dPAAoJELR76rQkz552ZBEP/3vkpftZnhsUkGhqXXptnRhz > +5A3n+BqFTsh4d4C15lcRcevwTyyQF61vrFKFRE7Cl5XVqVHowW0al+Dx7j5p35Mz > +PqBZUbEkBFc9xY8WasQYbJl5yDboc8Ora71SEJ1k59duETXmZ67ISpEe6HF3d2xK > +3BGfqaBMwU+Aql0pDMtysoOgEgs7d/Vin9gIXJcqAvw71bpNyZvFUln3do2eLC/v > +VW0bVvAN3B66fLx3li8hEZ4wfrg0Uui5zSN95+uc2DUGW03BNR/sKhYXstHAoqef > +4WIAD70e+9vArh8WqPTIUWl0w+1ixgVvGckHXHW10MdwkoVtwo4tawRxngLBKuI9 > +pUu7dc/TIVl15z/y1EmQ25rB4WV9M9W+uRauUi/T3c0hfSuZkB6B1tCu3QStPbWz > +AK3O6Neoni2NgMDLmrWzgDZA3Z/+h9RBV/kNda0RpbWZYJOJILBR+Q8+BZOwDZX/ > +hu/tITC7IHVJgMXYGlEFybEn/clbtLsZr8zLlSZyropl0mvUBLeBCrjYBQuDN86g > +yew/Tzs9T5MEFagUkbRERz5rP5OIE9XpXcHMsZve7cCL3YQy0LOkZk3RZKUsbv8g > +MVU1px5/ImBkr0MU0XZxstsAV0YPiON3+qMOnrdGuFx11YQi6cmIA2eww2KPqzHY > +YKirAGNintaD8yXAlwLd > +=wF8p > +-END PGP SIGNATURE- > + > + > +== 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` > + > + > +tree 14461762125c079e55a9684ae3a96e27de5b3f2f > +parent da19995926ec89e48297a3163b0f5190af3a8650 > +author Michael J Gruber 1325088101 +0100 > +committer Michael J Gruber 1325088101 +0100 > +gpgsig -BEGIN PGP SIGNATURE- > + Version: GnuPG v1.4.11 (GNU/Linux) > + > + iQIcBAABCgAGBQJO+z1lAAoJELR76rQkz552xOoQAJgV6sstR8cge760X7awb00V > + svN+pcc1TtJZecYWakCIe6dGPAK2Yk1AwExV0tbAQskPxYIqwnuysXHvVlmyJh5P > + 1N033YSRc8j59YNQNaLIAh6+c59cKcZdWQyrA1HFVWGqoafCD2+nMglb/JbN9jqQ > + 5gsxfFGoE0blT+BnMrchzPL4kjMJQBszV5ccATu3iIgSv23p5rA4tm3/P44enIsH > + U9nYODlKmzsAulThQoSd4Qk0MNIg86MjIXanPkj4S+TLLgDa6Zf8W3m28IiRwPF1 > + WemWpQ9VwSSHKuGVyHGG2OErtDDftILcYtjW5c/UnLw38hWPwc+KxVmAdEBY3vgk > + OACDEDLqAWgc4rLdWgkoxieIi0aKN+iN4kogbEtSl4VzgvX0iGLZP8cyJnGxHria > + Qz2UcesNqVPPqOxsIJKpr3CByrh2WDzH8W3tvGuy5q8EsTx5uF1HGoYb3PIx76QG > +
Re: [PATCH] grep: fix match highlighting for combined patterns with context lines
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 now. Happy if you squashed your > change (commit da736e6) in zk/grep-color-words branch. OK, will do. Thanks. -- 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-info.html
Re: [PATCH 03/15] refs.c: use packed refs when deleting refs during a transaction
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 packed refs
> file to stop anyone else from modifying these refs and keep it locked until
> we are finished.
> Since all refs we are about to delete are now safely held in the packed refs
> file we can proceed to immediately unlink any corresponding loose refs
> and still be fully rollback-able.
>
> The exception is for refs that can not be resolved. Those refs are never
> added to the packed refs and will just be un-rollback-ably deleted during
> commit.
>
> By deleting all the loose refs at the start of the transaction we make make
> it possible to both delete one ref and then re-create a different ref in
> the same transaction even if the two refs would normally conflict.
>
> Example: rename m->m/m
>
> In that example we want to delete the file 'm' so that we make room so
> that we can create a directory with the same name in order to lock and
> write to the ref m/m and its lock-file m/m.lock.
>
> If there is a failure during the commit phase we can rollback without losing
> any refs since we have so far only deleted loose refs that that are
> guaranteed to also have a corresponding entry in the packed refs file.
> Once we have finished all updates for refs and their reflogs we can repack
> the packed refs file and remove the to-be-deleted refs from the packed refs,
> at which point all the deleted refs will disappear in one atomic rename
> operation.
>
> This also means that for an outside observer, deletion of multiple refs
> in a single transaction will look atomic instead of one ref being deleted
> at a time.
>
> In order to do all this we need to change the semantics for the
> repack_without_refs function so that we can lock the packed refs file,
> do other stuff, and later be able to call repack_without_refs with the
> lock already taken.
> This means we need some additional changes in remote.c to reflect the
> changes to the repack_without_refs semantics.
>
> Change-Id: I1e4f58050acaabc6bcfa3409fbc0c2b866bb59aa
> Signed-off-by: Ronnie Sahlberg
> Signed-off-by: Jonathan Nieder
> @@ -3821,23 +3824,109 @@ int transaction_commit(struct transaction
> *transaction,
> ...
> + if (need_repack) {
> + packed = get_packed_refs(&ref_cache);;
> + sort_ref_dir(packed);
> + if (commit_packed_refs()){
SP between "){".
> + strbuf_addf(err, "unable to overwrite old ref-pack "
> + "file");
This is bending backwards sacrificing readability; 80-col limit is
not that hard a limit. Split at the comma instead, perhaps?
strbuf_addf(err,
"unable to overwrite old ref-pack file");
> ...
> + if (!update->lock) {
> + int df_conflict = (errno == ENOTDIR);
> +
> + strbuf_addf(err, "Cannot lock the ref '%s'.",
> + update->refname);
> + ret = df_conflict ?
> + TRANSACTION_NAME_CONFLICT :
A trailing SP here...
> @@ -3860,6 +3953,16 @@ int transaction_commit(struct transaction *transaction,
> update->reflog_lock = update->orig_update->reflog_lock;
> continue;
> }
> + if (log_all_ref_updates && !reflog_exists(update->refname) &&
> + create_reflog(update->refname)) {
> + ret = -1;
> + if (err)
> + strbuf_addf(err, "Failed to setup reflog for "
> + "%s", update->refname);
Split after comma, perhaps?
--
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-info.html
Plumbing version of 'git branch --contains' ?
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 $1 ${br}
if [ $? -eq 0 ]
then
echo "${br}"
fi
done
Which gives me perfect output, but takes 82 seconds to run in my environment.
Is there an alternative I'm missing to give me the run time performance of 'git
branch --contains' but with stable output suitable for parsing?
Thanks in advance,
-Andrew
--
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-info.html
Re: [PATCH 2/2] .mailmap: Add Stefan Bellers corporate mail address
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 I said, I do not care too deeply either way. If you feel that switching to a different e-mail address to sign off your patches from now on until your employment is terminated has merit to the project, that's fine by me. Thanks. -- 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-info.html
Re: [PATCHv2] push: heed user.signingkey for signed pushes
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 | 13 -
> t/lib-gpg/trustdb.gpg | Bin 1360 -> 1360 bytes
> t/t5534-push-signed.sh | 44
> 3 files changed, 56 insertions(+), 1 deletion(-)
Hmph, I simply forgot about that configuration, I guess.
What is this change to trustdb about, though? The log message does
not say anything about it.
>
> diff --git a/builtin/push.c b/builtin/push.c
> index ae56f73..a076b19 100644
> --- a/builtin/push.c
> +++ b/builtin/push.c
> @@ -471,6 +471,17 @@ static int option_parse_recurse_submodules(const struct
> option *opt,
> return 0;
> }
>
> +static int git_push_config(const char *k, const char *v, void *cb)
> +{
> + struct wt_status *s = cb;
> + int status;
> +
> + status = git_gpg_config(k, v, NULL);
> + if (status)
> + return status;
> + return git_default_config(k, v, s);
> +}
> +
> int cmd_push(int argc, const char **argv, const char *prefix)
> {
> int flags = 0;
> @@ -511,7 +522,7 @@ int cmd_push(int argc, const char **argv, const char
> *prefix)
> };
>
> packet_trace_identity("push");
> - git_config(git_default_config, NULL);
> + git_config(git_push_config, NULL);
> argc = parse_options(argc, argv, prefix, options, push_usage, 0);
>
> if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL |
> TRANSPORT_PUSH_MIRROR
> diff --git a/t/lib-gpg/trustdb.gpg b/t/lib-gpg/trustdb.gpg
> index
> 4879ae9a84650a93a4d15bd6560c5d1b89eb4c2f..c11b1464b3d13b45966a493e2174fc0e253ddd0c
> 100644
> GIT binary patch
> delta 47
> ncmcb>b%9HOF})z2nVFH5k%@sJ#C^}~iH71E)x}wb7%%_;=xPS!
>
> delta 51
> tcmcb>b%9HSF})z2nVFH5k%@sJ&}Z5*1_lPkiGso#)x}wb*nk{V008$D2C@JE
>
> diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh
> index 2786346..ecb8d44 100755
> --- a/t/t5534-push-signed.sh
> +++ b/t/t5534-push-signed.sh
> @@ -124,4 +124,48 @@ test_expect_success GPG 'signed push sends push
> certificate' '
> test_cmp expect dst/push-cert-status
> '
>
> +test_expect_success GPG 'fail without key and heed user.signingkey' '
> + prepare_dst &&
> + mkdir -p dst/.git/hooks &&
> + git -C dst config receive.certnonceseed sekrit &&
> + write_script dst/.git/hooks/post-receive <<-\EOF &&
> + # discard the update list
> + cat >/dev/null
> + # record the push certificate
> + if test -n "${GIT_PUSH_CERT-}"
> + then
> + git cat-file blob $GIT_PUSH_CERT >../push-cert
> + fi &&
> +
> + cat >../push-cert-status < + SIGNER=${GIT_PUSH_CERT_SIGNER-nobody}
> + KEY=${GIT_PUSH_CERT_KEY-nokey}
> + STATUS=${GIT_PUSH_CERT_STATUS-nostatus}
> + NONCE_STATUS=${GIT_PUSH_CERT_NONCE_STATUS-nononcestatus}
> + NONCE=${GIT_PUSH_CERT_NONCE-nononce}
> + E_O_F
> +
> + EOF
> +
> + unset GIT_COMMITTER_EMAIL &&
> + git config user.email hasno...@nowhere.com &&
> + test_must_fail git push --signed dst noop ff +noff &&
> + git config user.signingkey commit...@example.com &&
> + git push --signed dst noop ff +noff &&
> +
> + (
> + cat <<-\EOF &&
> + SIGNER=C O Mitter
> + KEY=13B6F51ECDDE430D
> + STATUS=G
> + NONCE_STATUS=OK
> + EOF
> + sed -n -e "s/^nonce /NONCE=/p" -e "/^$/q" dst/push-cert
> + ) >expect &&
> +
> + grep "$(git rev-parse noop ff) refs/heads/ff" dst/push-cert &&
> + grep "$(git rev-parse noop noff) refs/heads/noff" dst/push-cert &&
> + test_cmp expect dst/push-cert-status
> +'
> +
> test_done
--
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-info.html
Re: [PATCHv2] push: heed user.signingkey for signed pushes
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. Sorry. >> >> builtin/push.c | 13 - >> t/lib-gpg/trustdb.gpg | Bin 1360 -> 1360 bytes >> t/t5534-push-signed.sh | 44 >> 3 files changed, 56 insertions(+), 1 deletion(-) > > Hmph, I simply forgot about that configuration, I guess. > > What is this change to trustdb about, though? The log message does > not say anything about it. This is a related tangent, but I just tried this: $ git clone ... git.git $ cd git.git $ chmod a-w t/lib-gpg/* t/lib-gpg $ make test which makes GPG related tests to fail, as running GPG with the GNUPGHOME set there involves writing into the files in the directory (or removing and recreating). Perhaps GPG tests should create their own copy in the playpen (aka "trash directory") and use that as GNUPGHOME so that we do not have to write into the single shared directory? I wonder if automated parallel tests can intermittently fail because of this... -- 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-info.html
Re: Sources for 3.18-rc1 not uploaded
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 archive entry"? I doubt it, and the > > above is not relevant. The mode bits for the archive entry that it > > applies to does not come from there. > > The problem seem to be old tar versions which mis-take the extensions > for archive entries, aren't they? Yes. POSIX isn't clear on how unknown entries are to be handled. I've seen some Windows tar implementations extract GNU longlink extensions as files, which leads to a lot of pain. > My question to Brian still stands which existing users he was trying to > cater for with his patch. If there indeed are no existing affected users > besides the KUP users (as you seem to assume) it's a clear case. Pun > intended ;) The pax format is an extension of the tar format. All of the pax implementations I've seen on Linux (OpenBSD's and MirBSD's) don't actually understand the pax headers and emit them as files. 7zip does as well. I expect there are other Unix systems where tar itself doesn't understand pax headers, although I don't have access to anything other than Linux and FreeBSD. Since it's very common to extract tar archives in /tmp, I didn't want to leave world-writable files in /tmp (or anywhere else someone might get to them). While the contents probably aren't sensitive, a malicious user might fill someone's quota by "helpfully" appending /dev/zero to the file. And yes, users do these things. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
