* [PATCH v2 3/8] upload-pack: support hidden refs with protocol v2
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 15:58 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Brandon Williams, Jonathan Tan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqimzygmz6.fsf@gitster-ct.c.googlers.com>
From: Jeff King <peff@peff.net>
In the v2 protocol, upload-pack's advertisement has been moved to the
"ls-refs" command. That command does not respect hidden-ref config (like
transfer.hiderefs) at all, and advertises everything.
While there are some features that are not supported in v2 (e.g., v2
always allows fetching any sha1 without respect to advertisements), the
lack of this feature is not documented and is likely just a bug. Let's
make it work, as otherwise upgrading a server to a v2-capable git will
start exposing these refs that the repository admin has asked to remain
hidden.
Note that we depend on the config_context from the caller here to
realize that we should respect uploadpack.hiderefs. When run from the
"git-serve" tool, we won't have that context and will only respect
transfer.hiderefs. This should be OK, as git-serve is not actually used
for normal protocol operations.
Note also that we don't need to worry about the "An attempt to update
or delete a hidden ref by git push is rejected" feature of
receive.hideRefs, see git-config(1). This is because there's no v2
push protocol yet.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
ls-refs.c | 12 ++++++++++++
t/t5512-ls-remote.sh | 6 ++++++
2 files changed, 18 insertions(+)
diff --git a/ls-refs.c b/ls-refs.c
index e8e31475f0..8a8143338b 100644
--- a/ls-refs.c
+++ b/ls-refs.c
@@ -5,6 +5,7 @@
#include "argv-array.h"
#include "ls-refs.h"
#include "pkt-line.h"
+#include "config.h"
/*
* Check if one of the prefixes is a prefix of the ref.
@@ -40,6 +41,9 @@ static int send_ref(const char *refname, const struct object_id *oid,
const char *refname_nons = strip_namespace(refname);
struct strbuf refline = STRBUF_INIT;
+ if (ref_is_hidden(refname_nons, refname))
+ return 0;
+
if (!ref_match(&data->prefixes, refname))
return 0;
@@ -69,6 +73,12 @@ static int send_ref(const char *refname, const struct object_id *oid,
return 0;
}
+static int ls_refs_config(const char *var, const char *value,
+ void *config_context)
+{
+ return parse_hide_refs_config(var, value, config_context);
+}
+
int ls_refs(struct repository *r,
const char *config_section,
struct argv_array *keys,
@@ -78,6 +88,8 @@ int ls_refs(struct repository *r,
memset(&data, 0, sizeof(data));
+ git_config(ls_refs_config, (void *)config_section);
+
while (packet_reader_read(request) != PACKET_READ_FLUSH) {
const char *arg = request->line;
const char *out;
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index 32e722db2e..ca69636fd5 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -204,6 +204,12 @@ test_expect_success 'overrides work between mixed transfer/upload-pack hideRefs'
grep refs/tags/magic actual
'
+test_expect_success 'protocol v2 supports hiderefs' '
+ test_config uploadpack.hiderefs refs/tags &&
+ git -c protocol.version=2 ls-remote . >actual &&
+ ! grep refs/tags actual
+'
+
test_expect_success 'ls-remote --symref' '
git fetch origin &&
cat >expect <<-EOF &&
--
2.20.0.405.gbc1bbc6f85
^ permalink raw reply related
* [PATCH v2 2/8] parse_hide_refs_config: handle NULL section
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 15:58 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Brandon Williams, Jonathan Tan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqimzygmz6.fsf@gitster-ct.c.googlers.com>
From: Jeff King <peff@peff.net>
This helper function looks for config in two places: transfer.hiderefs,
or $section.hiderefs, where $section is passed in by the caller (and is
"uploadpack" or "receive", depending on the context).
In preparation for callers which do not even have that context (namely
the "git-serve" command), let's handle a NULL by looking only at
transfer.hiderefs (as opposed to segfaulting).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index f9936355cd..099e91d9cc 100644
--- a/refs.c
+++ b/refs.c
@@ -1267,7 +1267,8 @@ int parse_hide_refs_config(const char *var, const char *value, const char *secti
{
const char *key;
if (!strcmp("transfer.hiderefs", var) ||
- (!parse_config_key(var, section, NULL, NULL, &key) &&
+ (section &&
+ !parse_config_key(var, section, NULL, NULL, &key) &&
!strcmp(key, "hiderefs"))) {
char *ref;
int len;
--
2.20.0.405.gbc1bbc6f85
^ permalink raw reply related
* [PATCH v2 1/8] serve: pass "config context" through to individual commands
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 15:58 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Brandon Williams, Jonathan Tan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqimzygmz6.fsf@gitster-ct.c.googlers.com>
From: Jeff King <peff@peff.net>
In protocol v2, instead of just running "upload-pack", we have a generic
"serve" loop which runs command requests from the client. What used to
be "upload-pack" is now generally split into two operations: "ls-refs"
and "fetch". The latter knows it must respect uploadpack.* config, but
the former is not actually specific to a fetch operation (we do not yet
do v2 receive-pack, but eventually we may, and ls-refs would support
both operations).
However, ls-refs does need to know which operation we're performing, in
order to read the correct config (e.g., uploadpack.hiderefs versus
receive.hiderefs; we don't read _either_ right now, but this is the
first step to fixing that).
In the generic "git-serve" program, we don't have that information. But
in the protocol as it is actually used by clients, the client still asks
to run "git-upload-pack", and then issues an "ls-refs" from there. So we
_do_ know at that point that "uploadpack" is the right config context.
This patch teaches the protocol v2 "serve" code to pass that context
through to the individual commands (a future patch will teach ls-refs to
actually use it).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
builtin/upload-pack.c | 1 +
ls-refs.c | 4 +++-
ls-refs.h | 3 ++-
serve.c | 9 +++++----
serve.h | 7 +++++++
upload-pack.c | 4 ++--
upload-pack.h | 4 ++--
7 files changed, 22 insertions(+), 10 deletions(-)
diff --git a/builtin/upload-pack.c b/builtin/upload-pack.c
index 42dc4da5a1..67192cfa9e 100644
--- a/builtin/upload-pack.c
+++ b/builtin/upload-pack.c
@@ -52,6 +52,7 @@ int cmd_upload_pack(int argc, const char **argv, const char *prefix)
case protocol_v2:
serve_opts.advertise_capabilities = opts.advertise_refs;
serve_opts.stateless_rpc = opts.stateless_rpc;
+ serve_opts.config_context = "uploadpack";
serve(&serve_opts);
break;
case protocol_v1:
diff --git a/ls-refs.c b/ls-refs.c
index a06f12eca8..e8e31475f0 100644
--- a/ls-refs.c
+++ b/ls-refs.c
@@ -69,7 +69,9 @@ static int send_ref(const char *refname, const struct object_id *oid,
return 0;
}
-int ls_refs(struct repository *r, struct argv_array *keys,
+int ls_refs(struct repository *r,
+ const char *config_section,
+ struct argv_array *keys,
struct packet_reader *request)
{
struct ls_refs_data data;
diff --git a/ls-refs.h b/ls-refs.h
index b62877e8da..da26fc9824 100644
--- a/ls-refs.h
+++ b/ls-refs.h
@@ -4,7 +4,8 @@
struct repository;
struct argv_array;
struct packet_reader;
-extern int ls_refs(struct repository *r, struct argv_array *keys,
+extern int ls_refs(struct repository *r, const char *config_context,
+ struct argv_array *keys,
struct packet_reader *request);
#endif /* LS_REFS_H */
diff --git a/serve.c b/serve.c
index bda085f09c..70f89cf0d9 100644
--- a/serve.c
+++ b/serve.c
@@ -48,6 +48,7 @@ struct protocol_capability {
* This field should be NULL for capabilities which are not commands.
*/
int (*command)(struct repository *r,
+ const char *config_context,
struct argv_array *keys,
struct packet_reader *request);
};
@@ -158,7 +159,7 @@ enum request_state {
PROCESS_REQUEST_DONE,
};
-static int process_request(void)
+static int process_request(struct serve_options *opts)
{
enum request_state state = PROCESS_REQUEST_KEYS;
struct packet_reader reader;
@@ -222,7 +223,7 @@ static int process_request(void)
if (!command)
die("no command requested");
- command->command(the_repository, &keys, &reader);
+ command->command(the_repository, opts->config_context, &keys, &reader);
argv_array_clear(&keys);
return 0;
@@ -249,10 +250,10 @@ void serve(struct serve_options *options)
* a single request/response exchange
*/
if (options->stateless_rpc) {
- process_request();
+ process_request(options);
} else {
for (;;)
- if (process_request())
+ if (process_request(options))
break;
}
}
diff --git a/serve.h b/serve.h
index fe65ba9f46..d527224cbb 100644
--- a/serve.h
+++ b/serve.h
@@ -8,6 +8,13 @@ extern int has_capability(const struct argv_array *keys, const char *capability,
struct serve_options {
unsigned advertise_capabilities;
unsigned stateless_rpc;
+
+ /*
+ * Some operations may need to know the context when looking up config;
+ * e.g., set this to "uploadpack" to respect "uploadpack.hiderefs" (as
+ * opposed to "receive.hiderefs").
+ */
+ const char *config_context;
};
#define SERVE_OPTIONS_INIT { 0 }
extern void serve(struct serve_options *options);
diff --git a/upload-pack.c b/upload-pack.c
index 5e81f1ff24..914bbb40bc 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -1413,8 +1413,8 @@ enum fetch_state {
FETCH_DONE,
};
-int upload_pack_v2(struct repository *r, struct argv_array *keys,
- struct packet_reader *request)
+int upload_pack_v2(struct repository *r, const char *config_context,
+ struct argv_array *keys, struct packet_reader *request)
{
enum fetch_state state = FETCH_PROCESS_ARGS;
struct upload_pack_data data;
diff --git a/upload-pack.h b/upload-pack.h
index cab2178796..2a9f51197c 100644
--- a/upload-pack.h
+++ b/upload-pack.h
@@ -13,8 +13,8 @@ void upload_pack(struct upload_pack_options *options);
struct repository;
struct argv_array;
struct packet_reader;
-extern int upload_pack_v2(struct repository *r, struct argv_array *keys,
- struct packet_reader *request);
+extern int upload_pack_v2(struct repository *r, const char *config_context,
+ struct argv_array *keys, struct packet_reader *request);
struct strbuf;
extern int upload_pack_advertise(struct repository *r,
--
2.20.0.405.gbc1bbc6f85
^ permalink raw reply related
* [PATCH v2 0/8] protocol v2 fixes
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 15:58 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Brandon Williams, Jonathan Tan,
Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqimzygmz6.fsf@gitster-ct.c.googlers.com>
I figured it would be easier for everyone if I rolled this all into
one series instead of Junio & us needing to keep track of what's based
on what.
The only change I made to Jeff's patches is my SOB and adding a
paragraph to the end of his 3/3 saying that the v2 push protocol
doesn't have the same issue (because it doesn't exist yet). I had that
question in this thread, and thought it was useful to clarify it.
No changes to Jonathan's one patch, except my SOB.
For the rest I incorporated Jonathan's suggestions / fixes with some
amendments. The suggestion to use env --unset isn't portable (and
there's now a check for that while we're at it), so instead we support
"GIT_TEST_PROTOCOL_VERSION=" which'll ignore the environment value.
Other changes in my patches are more narrowly skipping tests, i.e. no
"unset" anymore except for those tests where we're only doing v1 and
v2 tests. I also removed the "env" use in those cases that don't need
it (where we use e.g. test_must_fail), instead we just set the env
variable ourselves with native shell syntax.
Jeff King (3):
serve: pass "config context" through to individual commands
parse_hide_refs_config: handle NULL section
upload-pack: support hidden refs with protocol v2
Jonathan Tan (1):
builtin/fetch-pack: support protocol version 2
Ævar Arnfjörð Bjarmason (4):
tests: add a check for unportable env --unset
tests: add a special setup where for protocol.version
tests: mark & fix tests broken under GIT_TEST_PROTOCOL_VERSION=1
tests: mark tests broken under GIT_TEST_PROTOCOL_VERSION=2
builtin/fetch-pack.c | 9 ++++++---
builtin/upload-pack.c | 1 +
ls-refs.c | 16 +++++++++++++++-
ls-refs.h | 3 ++-
protocol.c | 13 ++++++++++++-
refs.c | 3 ++-
serve.c | 9 +++++----
serve.h | 7 +++++++
t/README | 6 ++++++
t/check-non-portable-shell.pl | 1 +
t/t0410-partial-clone.sh | 3 ++-
t/t5400-send-pack.sh | 2 +-
t/t5500-fetch-pack.sh | 9 ++++++---
t/t5503-tagfollow.sh | 8 ++++----
t/t5512-ls-remote.sh | 14 ++++++++++----
t/t5515-fetch-merge-logic.sh | 2 +-
t/t5516-fetch-push.sh | 20 +++++++++++++-------
t/t5537-fetch-shallow.sh | 3 ++-
t/t5539-fetch-http-shallow.sh | 9 +++++----
t/t5541-http-push-smart.sh | 9 +++++++--
t/t5551-http-fetch-smart.sh | 19 +++++++++++--------
t/t5552-skipping-fetch-negotiator.sh | 4 ++--
t/t5570-git-daemon.sh | 2 +-
t/t5601-clone.sh | 11 +++++++++--
t/t5700-protocol-v1.sh | 1 +
t/t5702-protocol-v2.sh | 1 +
t/t7406-submodule-update.sh | 3 ++-
upload-pack.c | 4 ++--
upload-pack.h | 4 ++--
29 files changed, 139 insertions(+), 57 deletions(-)
--
2.20.0.405.gbc1bbc6f85
^ permalink raw reply
* Re: [PATCH] cherry-pick: do not error on non-merge commits when '-m 1' is specified
From: Sergey Organov @ 2018-12-13 15:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <87o99qylv5.fsf@javad.com>
Sergey Organov <sorganov@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sergey Organov <sorganov@gmail.com> writes:
>>
[...]
>>
>> The change to the code itself looks sane, but applying this patch
>> alone will break existing tests whose expectations must be updated,
>> and this new behaviour must be protected by a new test (or two) so
>> that we won't accidentally stop accepting "-m 1" for a single-parent
>> commit.
>
> I fixed most of the tests, but
>
> "t3510/4: cherry-pick persists opts correctly"
>
> is an offender for me. It looks like it [ab]uses current "-m 1" behavior
> just to stop in the middle of the sequence, and I'm not sure how to fix
> it most suitably.
I came up with the following as a preparatory change. Looks acceptable?
-- 8< --
t3510: stop using '-m 1' to force failure mid-sequence of cherry-picks
We are going to allow 'git cherry-pick -m 1' for non-merge commits, so
this method to force failure will stop to work.
Use '-m 4' instead as it's very unlikely we will ever have such an
octopus in this test setup.
Modified t/t3510-cherry-pick-sequence.sh
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index c84eeef..a873cf4 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -61,7 +61,8 @@ test_expect_success 'cherry-pick mid-cherry-pick-sequence' '
test_expect_success 'cherry-pick persists opts correctly' '
pristine_detach initial &&
- test_expect_code 128 git cherry-pick -s -m 1 --strategy=recursive -X patience -X ours initial..anotherpick &&
+ m=4 &&
+ test_expect_code 128 git cherry-pick -s -m $m --strategy=recursive -X patience -X ours initial..anotherpick &&
test_path_is_dir .git/sequencer &&
test_path_is_file .git/sequencer/head &&
test_path_is_file .git/sequencer/todo &&
@@ -69,7 +70,7 @@ test_expect_success 'cherry-pick persists opts correctly' '
echo "true" >expect &&
git config --file=.git/sequencer/opts --get-all options.signoff >actual &&
test_cmp expect actual &&
- echo "1" >expect &&
+ echo "$m" >expect &&
git config --file=.git/sequencer/opts --get-all options.mainline >actual &&
test_cmp expect actual &&
echo "recursive" >expect &&
-- 8< --
--
Sergey
^ permalink raw reply related
* [Question] Complex textconv text
From: Randall S. Becker @ 2018-12-13 15:07 UTC (permalink / raw)
To: git
Hi all,
I have a strange situation and need help with resolving funky characters in
.git/config. My situation is this:
[diff "*.dat"]
textconv = enscribe-conv
--format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224
Basically this is a formatter for diff so that I can show structured binary
data. The unquoted syntax of the format string is:
--format=-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224
Content is not really important. The issue is that git is reporting fatal:
bad config line 2 in file .git/config when I escape the (, ), and |
characters. I get syntax errors otherwise from the shell running the
textconv. I have tried
--format="-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224", to no
avail. How should I safely escape the characters in here?
Thanks,
Randall
-- Brief whoami:
NonStop developer since approximately 211288444200000000
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
^ permalink raw reply
* Pre-commit hook does not work properly in recent version
From: Andrew Kharchenko @ 2018-12-13 15:03 UTC (permalink / raw)
To: git
Hello,
I found a bug in Git v. 2.20.0 and 2.19.x at least, where pre-commit hook does not work properly.
OS: macOS High Sierra
Git: 2.20.0, 2.19.x
Description: pre-commit file should be marked as executable in order to recreate the bug. When executing “git commit”, it silently exits without any message.
It was found, that Git version 2.17.1 still works as expected.
—
Sincerely,
Andrew Kharchenko
^ permalink raw reply
* Re: 2.20.0 - Undocumented change in submodule update wrt # parallel jobs
From: Junio C Hamano @ 2018-12-13 14:17 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, Sjon Hortensius
In-Reply-To: <CAHef355RQt9gN-7QjuAAT8mZsNFKfCo4hOYi2+bkp-0Av7W=Qw@mail.gmail.com>
Sjon Hortensius <sjon@parse.nl> writes:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended) change in
> https://github.com/git/git/commit/90efe595c53f4bb1851371344c35eff71f604d2b
> which removed the default of max_jobs=1
>
> While this can easily be fixed by configuring submodule.fetchJobs I
> think this change should be documented - or reverted back to it's
> previous default of 1
The commit in question does not look like it _wanted_ to change the
default; rather, it appears to me that it wanted to be bug-to-bug
compatible with the original, and any such change of behaviour is
entirely unintended.
I think the attached may be sufficient to change the default
max_jobs back to 1.
By the way, is there a place where we document that the default
value for fetchjobs, when unconfigured, is 1? If we are not making
such a concrete promise, then I would think it is OK to update the
default without any fanfare, as long as we have good reasons to do
so. For this particular one, however, as I already said, I do not
think we wanted to change the default to unlimited or anything like
that, so...
builtin/submodule--helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index 789d00d87d..e8cdf84f1c 100644
--- a/builtin/submodule--helper.c
+++ b/builtin/submodule--helper.c
@@ -1552,7 +1552,7 @@ struct submodule_update_clone {
#define SUBMODULE_UPDATE_CLONE_INIT {0, MODULE_LIST_INIT, 0, \
SUBMODULE_UPDATE_STRATEGY_INIT, 0, 0, -1, STRING_LIST_INIT_DUP, 0, \
NULL, NULL, NULL, \
- NULL, 0, 0, 0, NULL, 0, 0, 0}
+ NULL, 0, 0, 0, NULL, 0, 0, 1}
static void next_submodule_warn_missing(struct submodule_update_clone *suc,
^ permalink raw reply related
* Re: Preparing for 2.20.1 brown-paper-bag maintenance release
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 14:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Derrick Stolee,
Nguyễn Thái Ngọc Duy
In-Reply-To: <xmqq4lbiey7s.fsf@gitster-ct.c.googlers.com>
On Thu, Dec 13 2018, Junio C Hamano wrote:
> Here is an excerpt from a draft edition of "What's cooking" report
> for topics that are about an immediate 2.20.1 maintenance release,
> with five topics that I plan to merge to 'next' and then to 'maint'
> soonish (they're all marked as "Will merge to 'next' and then to
> 'master'").
>
> They'll be in 'pu' but not in 'next' in today's pushout, but unless
> I hear breakage reports in time, I am hoping to merge them to 'next'
> during tomorrow's integration cycle, so that we can start the new
> week with 2.20.1.
> [...]
> * nd/show-gitcomp-compilation-fix (2018-12-12) 1 commit
> - parse-options: fix SunCC compiler warning
>
> Portability fix for a recent update to parse-options API.
Since I reported this, just a clarification: Unlike 46c0eb5843
("files-backend.c: fix build error on Solaris", 2018-11-25) this one's
not an error on suncc, just a warning (and we have 20-30 of those exact
warnings in our code).
So if you wanted to minimize 2.20.1 this could be held back, but also it
looks obviously correct so it's fine that it makes it into that point
release. Just FYI.
^ permalink raw reply
* [PATCH v2 0/1] Fix regression in t9902 with NO_PERL
From: Johannes Schindelin via GitGitGadget @ 2018-12-13 14:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <pull.99.git.gitgitgadget@gmail.com>
The oneline notwithstanding, 13374987dd (completion: use _gitcompbuiltin for
format-patch, 2018-11-03) changed also the way send-email options are
completed, by asking the git send-email command itself what options it
offers.
Necessarily, this must fail when built with NO_PERL because send-email
itself is a Perl script. Which means that we need the PERL prerequisite for
the send-email test case in t9902.
Changes since v1:
* replaced the commit message by the cover letter, as it was deemed to be
more informative.
Johannes Schindelin (1):
t9902: 'send-email' test case requires PERL
t/t9902-completion.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-99%2Fdscho%2Ft9902-no-perl-fix-v2
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-99/dscho/t9902-no-perl-fix-v2
Pull-Request: https://github.com/gitgitgadget/git/pull/99
Range-diff vs v1:
1: 32e6bf2dd3 ! 1: 8e3ddff2c7 t9902: 'send-email' test case requires PERL
@@ -2,14 +2,14 @@
t9902: 'send-email' test case requires PERL
- With NO_PERL, the `git send-email` script errors out with code 128,
- mentioning that Git was built without Perl support.
+ The oneline notwithstanding, 13374987dd (completion: use _gitcompbuiltin
+ for format-patch, 2018-11-03) changed also the way send-email options
+ are completed, by asking the git send-email command itself what options
+ it offers.
- Therefore, when the completion tries to ask for possible completions via
- `git send-email --git-completion-helper`, it won't provide what is
- necessary for that test case to pass.
-
- So let's mark it with the PERL prerequisite.
+ Necessarily, this must fail when built with NO_PERL because send-email
+ itself is a Perl script. Which means that we need the PERL prerequisite
+ for the send-email test case in t9902.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
--
gitgitgadget
^ permalink raw reply
* [PATCH v2 1/1] t9902: 'send-email' test case requires PERL
From: Johannes Schindelin via GitGitGadget @ 2018-12-13 14:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <pull.99.v2.git.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
The oneline notwithstanding, 13374987dd (completion: use _gitcompbuiltin
for format-patch, 2018-11-03) changed also the way send-email options
are completed, by asking the git send-email command itself what options
it offers.
Necessarily, this must fail when built with NO_PERL because send-email
itself is a Perl script. Which means that we need the PERL prerequisite
for the send-email test case in t9902.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t9902-completion.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index d01ad8eb25..137fdc9bd5 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -1539,7 +1539,7 @@ test_expect_success 'complete tree filename with metacharacters' '
EOF
'
-test_expect_success 'send-email' '
+test_expect_success PERL 'send-email' '
test_completion "git send-email --cov" "--cover-letter " &&
test_completion "git send-email ma" "master "
'
--
gitgitgadget
^ permalink raw reply related
* Re: 2.20.0 - Undocumented change in submodule update wrt # parallel jobs
From: Ævar Arnfjörð Bjarmason @ 2018-12-13 14:02 UTC (permalink / raw)
To: Sjon Hortensius; +Cc: git
In-Reply-To: <CAHef355RQt9gN-7QjuAAT8mZsNFKfCo4hOYi2+bkp-0Av7W=Qw@mail.gmail.com>
On Thu, Dec 13 2018, Sjon Hortensius wrote:
> When switching to 2.20 our `git submodule update' (which clones
> through ssh) broke because our ssh-server rejected the ~20
> simultaneous connections the git-client makes. This seems to be caused
> by a (possibly unintended) change in
> https://github.com/git/git/commit/90efe595c53f4bb1851371344c35eff71f604d2b
> which removed the default of max_jobs=1
>
> While this can easily be fixed by configuring submodule.fetchJobs I
> think this change should be documented - or reverted back to it's
> previous default of 1
Just to add to this. SSH-ing with -j<ncores> (which I assume that ~20
is) is going to run into MaxStartups in sshd_config, which is especially
annoying as it's pre-ssh-auth, so the server doesn't even get "so and so
tried to login", it's just dropped as a potential DoS attack.
^ permalink raw reply
* Re: [PATCH 0/1] Fix regression in t9902 with NO_PERL
From: Johannes Schindelin @ 2018-12-13 13:52 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Johannes Schindelin via GitGitGadget, git, Junio C Hamano
In-Reply-To: <20181213132707.GX30222@szeder.dev>
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]
Hi Gábor,
On Thu, 13 Dec 2018, SZEDER Gábor wrote:
> On Thu, Dec 13, 2018 at 05:01:11AM -0800, Johannes Schindelin via GitGitGadget wrote:
> > The oneline notwithstanding,13374987dd (completion: use
> > _gitcompbuiltin for format-patch, 2018-11-03) changed also the way
> > send-email options are completed, by asking the git send-email command
> > itself what options it offers.
> >
> > Necessarily, this must fail when built with NO_PERL because send-email
> > itself is a Perl script. Which means that we need the PERL
> > prerequisite for the send-email test case in t9902.
>
> I find this text in the cover letter to be a better commit message than
> the text in the patch itself, because mentions when it broke and clearly
> mentions why it broke.
Okay, I replaced the commit message.
Ciao,
Dscho
>
> > Johannes Schindelin (1):
> > t9902: 'send-email' test case requires PERL
> >
> > t/t9902-completion.sh | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >
> > base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
> > Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-99%2Fdscho%2Ft9902-no-perl-fix-v1
> > Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-99/dscho/t9902-no-perl-fix-v1
> > Pull-Request: https://github.com/gitgitgadget/git/pull/99
> > --
> > gitgitgadget
>
^ permalink raw reply
* Re: [RFC/PATCH] Use mailmap by default in log, show and whatchanged
From: Johannes Schindelin @ 2018-12-13 13:49 UTC (permalink / raw)
To: CB Bailey; +Cc: git
In-Reply-To: <20181213120940.26477-1-cb@hashpling.org>
Hi CB,
On Thu, 13 Dec 2018, CB Bailey wrote:
> From: CB Bailey <cbailey32@bloomberg.net>
>
> People who have changed their name or email address will usually know
> that they need to set 'log.mailmap' in order to have their new details
> reflected for old commits with 'git log', but others who interact with
> them may not know or care enough to enable this option.
>
> Change the default for 'git log' and friends to always use mailmap so
> that everyone gets to see canonical names and email addresses.
>
> Signed-off-by: CB Bailey <cbailey32@bloomberg.net>
> ---
>
> Related to my patch to make shortlog pass the mailmap into the revision
> walker which may end up being configuratble behavior, I thought I'd
> propose this for discussion.
>
> For people who change their names during their involvement in a project,
> it can be important that the people with whom they work only see their
> correct name, even when browsing old history.
This makes a ton of sense to me.
Thank you,
Dscho
>
> I had a dig around in the mailing list archives and couldn't find any
> specific reason not to use a mailmap in log where one is in use. I did
> find this message which suggests that it makes sense to make it the
> default for human-consumed formats. This patch doesn't affect
> "--pretty=raw" formatting.
>
> Documentation/config/log.txt | 4 ++--
> Documentation/git-log.txt | 12 +++++++++---
> builtin/log.c | 2 +-
> t/t4203-mailmap.sh | 18 ++++++++++++++++++
> 4 files changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/config/log.txt b/Documentation/config/log.txt
> index 78d9e4453a..8a01eed46b 100644
> --- a/Documentation/config/log.txt
> +++ b/Documentation/config/log.txt
> @@ -39,5 +39,5 @@ log.showSignature::
> linkgit:git-whatchanged[1] assume `--show-signature`.
>
> log.mailmap::
> - If true, makes linkgit:git-log[1], linkgit:git-show[1], and
> - linkgit:git-whatchanged[1] assume `--use-mailmap`.
> + If false, makes linkgit:git-log[1], linkgit:git-show[1], and
> + linkgit:git-whatchanged[1] assume `--no-use-mailmap`.
> diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
> index 90761f1694..7815c9a6cb 100644
> --- a/Documentation/git-log.txt
> +++ b/Documentation/git-log.txt
> @@ -50,9 +50,11 @@ OPTIONS
> commit was reached.
>
> --use-mailmap::
> - Use mailmap file to map author and committer names and email
> - addresses to canonical real names and email addresses. See
> - linkgit:git-shortlog[1].
> +--no-use-mailmap::
> + Use (or don't use) mailmap file to map author and committer names and
> + email addresses to canonical real names and email addresses. The default
> + is to use the mailmap file, but this can be overriden with the
> + `log.mailmap` configuration option. See linkgit:git-shortlog[1].
>
> --full-diff::
> Without this flag, `git log -p <path>...` shows commits that
> @@ -205,6 +207,10 @@ log.showRoot::
> `git log -p` output would be shown without a diff attached.
> The default is `true`.
>
> +log.mailmap::
> + If `false`, makes `git log` and related commands assume
> + `--no-use-mailmap`.
> +
> log.showSignature::
> If `true`, `git log` and related commands will act as if the
> `--show-signature` option was passed to them.
> diff --git a/builtin/log.c b/builtin/log.c
> index e8e51068bd..41a5eefb20 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -46,7 +46,7 @@ static int default_follow;
> static int default_show_signature;
> static int decoration_style;
> static int decoration_given;
> -static int use_mailmap_config;
> +static int use_mailmap_config = 1;
> static const char *fmt_patch_subject_prefix = "PATCH";
> static const char *fmt_pretty;
>
> diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
> index 43b1522ea2..efb145c4cd 100755
> --- a/t/t4203-mailmap.sh
> +++ b/t/t4203-mailmap.sh
> @@ -424,6 +424,24 @@ EOF
>
> test_expect_success 'Log output with --use-mailmap' '
> git log --use-mailmap | grep Author >actual &&
> + test_cmp expect actual &&
> +# --use-mailmap is the default
> + git log | grep Author >actual &&
> + test_cmp expect actual
> +'
> +
> +cat >expect <<\EOF
> +Author: CTO <cto@coompany.xx>
> +Author: claus <me@company.xx>
> +Author: santa <me@company.xx>
> +Author: nick2 <nick2@company.xx>
> +Author: nick2 <bugs@company.xx>
> +Author: nick1 <bugs@company.xx>
> +Author: A U Thor <author@example.com>
> +EOF
> +
> +test_expect_success 'Log output with --no-use-mailmap' '
> + git log --no-use-mailmap | grep Author >actual &&
> test_cmp expect actual
> '
>
> --
> 2.20.0
>
>
^ permalink raw reply
* Re: [PATCH 1/1] .gitattributes: ensure t/oid-info/* has eol=lf
From: Johannes Schindelin @ 2018-12-13 13:44 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Derrick Stolee via GitGitGadget, git, Junio C Hamano,
Derrick Stolee
In-Reply-To: <20181213132254.GW30222@szeder.dev>
[-- Attachment #1: Type: text/plain, Size: 1365 bytes --]
Hi Gábor,
On Thu, 13 Dec 2018, SZEDER Gábor wrote:
> On Thu, Dec 13, 2018 at 02:01:15PM +0100, Johannes Schindelin wrote:
> >
> > On Wed, 12 Dec 2018, SZEDER Gábor wrote:
> >
> > > On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget wrote:
> > > > From: Derrick Stolee <dstolee@microsoft.com>
> > > >
> > > > The new test_oid machinery in the test library requires reading
> > > > some information from t/oid-info/hash-info and t/oid-info/oid.
> > > > The shell logic that reads from these files is sensitive to CRLF
> > > > line endings, causing a problem when the test suite is run on a
> > > > Windows machine that converts LF to CRLF.
> > >
> > > "What problem?" is what people will ask when they read this commit
> > > message in the future.
> >
> > The test script (not test case) fails with the rather terrifying message
> >
> > error: bug in the test script: bad hash algorithm
> >
> > See e.g. line 958 of the Build & Test log in the Windows phase of
> > https://dev.azure.com/git-for-windows/git/_build/results?buildId=26757
>
> Yeah, I saw that in the cover letter. And that was my point, that I
> saw this there, not in the proposed commit log message:
>
> > > Please include the relevant details in the commit message instead of
> > > the cover letter.
Oy, oy, oy. I missed that. Where is the coffee.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/1] Fix regression in t9902 with NO_PERL
From: SZEDER Gábor @ 2018-12-13 13:27 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Junio C Hamano
In-Reply-To: <pull.99.git.gitgitgadget@gmail.com>
On Thu, Dec 13, 2018 at 05:01:11AM -0800, Johannes Schindelin via GitGitGadget wrote:
> The oneline notwithstanding,13374987dd (completion: use _gitcompbuiltin for
> format-patch, 2018-11-03) changed also the way send-email options are
> completed, by asking the git send-email command itself what options it
> offers.
>
> Necessarily, this must fail when built with NO_PERL because send-email
> itself is a Perl script. Which means that we need the PERL prerequisite for
> the send-email test case in t9902.
I find this text in the cover letter to be a better commit message
than the text in the patch itself, because mentions when it broke and
clearly mentions why it broke.
> Johannes Schindelin (1):
> t9902: 'send-email' test case requires PERL
>
> t/t9902-completion.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>
> base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
> Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-99%2Fdscho%2Ft9902-no-perl-fix-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-99/dscho/t9902-no-perl-fix-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/99
> --
> gitgitgadget
^ permalink raw reply
* Re: [PATCH 1/1] .gitattributes: ensure t/oid-info/* has eol=lf
From: SZEDER Gábor @ 2018-12-13 13:22 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Derrick Stolee via GitGitGadget, git, Junio C Hamano,
Derrick Stolee
In-Reply-To: <nycvar.QRO.7.76.6.1812131358530.43@tvgsbejvaqbjf.bet>
On Thu, Dec 13, 2018 at 02:01:15PM +0100, Johannes Schindelin wrote:
> Hi Gábor,
>
> On Wed, 12 Dec 2018, SZEDER Gábor wrote:
>
> > On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget wrote:
> > > From: Derrick Stolee <dstolee@microsoft.com>
> > >
> > > The new test_oid machinery in the test library requires reading
> > > some information from t/oid-info/hash-info and t/oid-info/oid.
> > > The shell logic that reads from these files is sensitive to CRLF
> > > line endings, causing a problem when the test suite is run on a
> > > Windows machine that converts LF to CRLF.
> >
> > "What problem?" is what people will ask when they read this commit
> > message in the future.
>
> The test script (not test case) fails with the rather terrifying message
>
> error: bug in the test script: bad hash algorithm
>
> See e.g. line 958 of the Build & Test log in the Windows phase of
> https://dev.azure.com/git-for-windows/git/_build/results?buildId=26757
Yeah, I saw that in the cover letter. And that was my point, that I
saw this there, not in the proposed commit log message:
> > Please include the relevant details in the commit message instead of
> > the cover letter.
^ permalink raw reply
* Re: [PATCH v2 1/3] http: add support for selecting SSL backends at runtime
From: Johannes Schindelin @ 2018-12-13 13:15 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Schindelin via GitGitGadget, git, Junio C Hamano
In-Reply-To: <nycvar.QRO.7.76.6.1812131403310.43@tvgsbejvaqbjf.bet>
[-- Attachment #1: Type: text/plain, Size: 6083 bytes --]
Hi,
On Thu, 13 Dec 2018, Johannes Schindelin wrote:
> On Thu, 13 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
>
> > On Thu, Oct 25 2018, Johannes Schindelin via GitGitGadget wrote:
> >
> > > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> > >
> > > As of version 7.56.0, curl supports being compiled with multiple SSL
> > > backends.
> > >
> > > This patch adds the Git side of that feature: by setting http.sslBackend
> > > to "openssl" or "schannel", Git for Windows can now choose the SSL
> > > backend at runtime.
> > >
> > > This comes in handy on Windows because Secure Channel ("schannel") is
> > > the native solution, accessing the Windows Credential Store, thereby
> > > allowing for enterprise-wide management of certificates. For historical
> > > reasons, Git for Windows needs to support OpenSSL still, as it has
> > > previously been the only supported SSL backend in Git for Windows for
> > > almost a decade.
> > >
> > > The patch has been carried in Git for Windows for over a year, and is
> > > considered mature.
> > >
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > ---
> > > Documentation/config.txt | 5 +++++
> > > http.c | 35 +++++++++++++++++++++++++++++++++++
> > > 2 files changed, 40 insertions(+)
> > >
> > > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > > index 154683321..7d38f0bf1 100644
> > > --- a/Documentation/config.txt
> > > +++ b/Documentation/config.txt
> > > @@ -1984,6 +1984,11 @@ http.sslCAPath::
> > > with when fetching or pushing over HTTPS. Can be overridden
> > > by the `GIT_SSL_CAPATH` environment variable.
> > >
> > > +http.sslBackend::
> > > + Name of the SSL backend to use (e.g. "openssl" or "schannel").
> > > + This option is ignored if cURL lacks support for choosing the SSL
> > > + backend at runtime.
> > > +
> > > http.pinnedpubkey::
> > > Public key of the https service. It may either be the filename of
> > > a PEM or DER encoded public key file or a string starting with
> > > diff --git a/http.c b/http.c
> > > index 98ff12258..7fb37a061 100644
> > > --- a/http.c
> > > +++ b/http.c
> > > @@ -155,6 +155,8 @@ static struct active_request_slot *active_queue_head;
> > >
> > > static char *cached_accept_language;
> > >
> > > +static char *http_ssl_backend;
> > > +
> > > size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
> > > {
> > > size_t size = eltsize * nmemb;
> > > @@ -302,6 +304,12 @@ static int http_options(const char *var, const char *value, void *cb)
> > > curl_ssl_try = git_config_bool(var, value);
> > > return 0;
> > > }
> > > + if (!strcmp("http.sslbackend", var)) {
> > > + free(http_ssl_backend);
> > > + http_ssl_backend = xstrdup_or_null(value);
> > > + return 0;
> > > + }
> > > +
> > > if (!strcmp("http.minsessions", var)) {
> > > min_curl_sessions = git_config_int(var, value);
> > > #ifndef USE_CURL_MULTI
> > > @@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
> > > git_config(urlmatch_config_entry, &config);
> > > free(normalized_url);
> > >
> > > +#if LIBCURL_VERSION_NUM >= 0x073800
> > > + if (http_ssl_backend) {
> > > + const curl_ssl_backend **backends;
> > > + struct strbuf buf = STRBUF_INIT;
> > > + int i;
> > > +
> > > + switch (curl_global_sslset(-1, http_ssl_backend, &backends)) {
> > > + case CURLSSLSET_UNKNOWN_BACKEND:
> > > + strbuf_addf(&buf, _("Unsupported SSL backend '%s'. "
> > > + "Supported SSL backends:"),
> > > + http_ssl_backend);
> > > + for (i = 0; backends[i]; i++)
> > > + strbuf_addf(&buf, "\n\t%s", backends[i]->name);
> > > + die("%s", buf.buf);
> > > + case CURLSSLSET_NO_BACKENDS:
> > > + die(_("Could not set SSL backend to '%s': "
> > > + "cURL was built without SSL backends"),
> > > + http_ssl_backend);
> > > + case CURLSSLSET_TOO_LATE:
> > > + die(_("Could not set SSL backend to '%s': already set"),
> > > + http_ssl_backend);
> > > + case CURLSSLSET_OK:
> > > + break; /* Okay! */
> > > + }
> > > + }
> > > +#endif
> > > +
> > > if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
> > > die("curl_global_init failed");
> >
> > Here's someone who upgraded to 2.20 on Arch linux & started getting
> > "Could not set..." errors because of this change:
> > https://www.reddit.com/r/git/comments/a5ne5v/git_fatal_could_not_set_ssl_backend_to_openssl/
>
> Yeah, I don't see bug reports that were opened via Reddit.
>
> > I don't know the context well enough, but is there perhaps enough info
> > here so we could give a better error message, e.g. "don't set xyz twice
> > in your config", or just emit a warning?
>
> This is actually not the symptom of a Git bug, but of a cURL bug that I
> fixed in https://github.com/curl/curl/pull/3346. I suspect the fix for
> this particular symptom to be
> https://github.com/curl/curl/commit/231a328c1c563acb53d8222894975e96bf7e6ea7
I should actually talk about that symptom a bit more so you understand
where it comes from: the idea of cURL when compiled with multiple TLS
backends is that it has a meta backend that, upon first call, will see
which backend to use and then plugs that.
When compiled with a single backend, that meta backend is not plugged at
all, the single backend is plugged by default.
And here lies the rub, when *now* trying to select a TLS backend *by
name*, the code incorrectly reported an error (instead of success in case
that the correct backend was already "selected", or *another* failure if
trying to select a backend that was not compiled in).
Ciao,
Dscho
> (Granted, I introduced that bug, and did not catch it earlier because I
> almost never build cURL with a single TLS backend these days, and that is
> necessary to trigger the bug.)
>
> According to https://curl.haxx.se/changes.html, this bug fix
> (https://curl.haxx.se/bug/?i=3346) made it into v7.63.0, which is one day
> old.
>
> Feel free to update that Reddit post (I don't have an account, nor any
> inclination to get one).
>
> Ciao,
> Dscho
^ permalink raw reply
* Re: [PATCH v2 1/3] http: add support for selecting SSL backends at runtime
From: Johannes Schindelin @ 2018-12-13 13:08 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Johannes Schindelin via GitGitGadget, git, Junio C Hamano
In-Reply-To: <87sgz1n53e.fsf@evledraar.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5116 bytes --]
Hi Ævar,
On Thu, 13 Dec 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Oct 25 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
> >
> > As of version 7.56.0, curl supports being compiled with multiple SSL
> > backends.
> >
> > This patch adds the Git side of that feature: by setting http.sslBackend
> > to "openssl" or "schannel", Git for Windows can now choose the SSL
> > backend at runtime.
> >
> > This comes in handy on Windows because Secure Channel ("schannel") is
> > the native solution, accessing the Windows Credential Store, thereby
> > allowing for enterprise-wide management of certificates. For historical
> > reasons, Git for Windows needs to support OpenSSL still, as it has
> > previously been the only supported SSL backend in Git for Windows for
> > almost a decade.
> >
> > The patch has been carried in Git for Windows for over a year, and is
> > considered mature.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > Documentation/config.txt | 5 +++++
> > http.c | 35 +++++++++++++++++++++++++++++++++++
> > 2 files changed, 40 insertions(+)
> >
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 154683321..7d38f0bf1 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -1984,6 +1984,11 @@ http.sslCAPath::
> > with when fetching or pushing over HTTPS. Can be overridden
> > by the `GIT_SSL_CAPATH` environment variable.
> >
> > +http.sslBackend::
> > + Name of the SSL backend to use (e.g. "openssl" or "schannel").
> > + This option is ignored if cURL lacks support for choosing the SSL
> > + backend at runtime.
> > +
> > http.pinnedpubkey::
> > Public key of the https service. It may either be the filename of
> > a PEM or DER encoded public key file or a string starting with
> > diff --git a/http.c b/http.c
> > index 98ff12258..7fb37a061 100644
> > --- a/http.c
> > +++ b/http.c
> > @@ -155,6 +155,8 @@ static struct active_request_slot *active_queue_head;
> >
> > static char *cached_accept_language;
> >
> > +static char *http_ssl_backend;
> > +
> > size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void *buffer_)
> > {
> > size_t size = eltsize * nmemb;
> > @@ -302,6 +304,12 @@ static int http_options(const char *var, const char *value, void *cb)
> > curl_ssl_try = git_config_bool(var, value);
> > return 0;
> > }
> > + if (!strcmp("http.sslbackend", var)) {
> > + free(http_ssl_backend);
> > + http_ssl_backend = xstrdup_or_null(value);
> > + return 0;
> > + }
> > +
> > if (!strcmp("http.minsessions", var)) {
> > min_curl_sessions = git_config_int(var, value);
> > #ifndef USE_CURL_MULTI
> > @@ -995,6 +1003,33 @@ void http_init(struct remote *remote, const char *url, int proactive_auth)
> > git_config(urlmatch_config_entry, &config);
> > free(normalized_url);
> >
> > +#if LIBCURL_VERSION_NUM >= 0x073800
> > + if (http_ssl_backend) {
> > + const curl_ssl_backend **backends;
> > + struct strbuf buf = STRBUF_INIT;
> > + int i;
> > +
> > + switch (curl_global_sslset(-1, http_ssl_backend, &backends)) {
> > + case CURLSSLSET_UNKNOWN_BACKEND:
> > + strbuf_addf(&buf, _("Unsupported SSL backend '%s'. "
> > + "Supported SSL backends:"),
> > + http_ssl_backend);
> > + for (i = 0; backends[i]; i++)
> > + strbuf_addf(&buf, "\n\t%s", backends[i]->name);
> > + die("%s", buf.buf);
> > + case CURLSSLSET_NO_BACKENDS:
> > + die(_("Could not set SSL backend to '%s': "
> > + "cURL was built without SSL backends"),
> > + http_ssl_backend);
> > + case CURLSSLSET_TOO_LATE:
> > + die(_("Could not set SSL backend to '%s': already set"),
> > + http_ssl_backend);
> > + case CURLSSLSET_OK:
> > + break; /* Okay! */
> > + }
> > + }
> > +#endif
> > +
> > if (curl_global_init(CURL_GLOBAL_ALL) != CURLE_OK)
> > die("curl_global_init failed");
>
> Here's someone who upgraded to 2.20 on Arch linux & started getting
> "Could not set..." errors because of this change:
> https://www.reddit.com/r/git/comments/a5ne5v/git_fatal_could_not_set_ssl_backend_to_openssl/
Yeah, I don't see bug reports that were opened via Reddit.
> I don't know the context well enough, but is there perhaps enough info
> here so we could give a better error message, e.g. "don't set xyz twice
> in your config", or just emit a warning?
This is actually not the symptom of a Git bug, but of a cURL bug that I
fixed in https://github.com/curl/curl/pull/3346. I suspect the fix for
this particular symptom to be
https://github.com/curl/curl/commit/231a328c1c563acb53d8222894975e96bf7e6ea7
(Granted, I introduced that bug, and did not catch it earlier because I
almost never build cURL with a single TLS backend these days, and that is
necessary to trigger the bug.)
According to https://curl.haxx.se/changes.html, this bug fix
(https://curl.haxx.se/bug/?i=3346) made it into v7.63.0, which is one day
old.
Feel free to update that Reddit post (I don't have an account, nor any
inclination to get one).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/1] .gitattributes: ensure t/oid-info/* has eol=lf
From: Johannes Schindelin @ 2018-12-13 13:01 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Derrick Stolee via GitGitGadget, git, Junio C Hamano,
Derrick Stolee
In-Reply-To: <20181212133945.GV30222@szeder.dev>
[-- Attachment #1: Type: text/plain, Size: 1546 bytes --]
Hi Gábor,
On Wed, 12 Dec 2018, SZEDER Gábor wrote:
> On Tue, Dec 11, 2018 at 12:35:46PM -0800, Derrick Stolee via GitGitGadget wrote:
> > From: Derrick Stolee <dstolee@microsoft.com>
> >
> > The new test_oid machinery in the test library requires reading
> > some information from t/oid-info/hash-info and t/oid-info/oid.
> > The shell logic that reads from these files is sensitive to CRLF
> > line endings, causing a problem when the test suite is run on a
> > Windows machine that converts LF to CRLF.
>
> "What problem?" is what people will ask when they read this commit
> message in the future.
The test script (not test case) fails with the rather terrifying message
error: bug in the test script: bad hash algorithm
See e.g. line 958 of the Build & Test log in the Windows phase of
https://dev.azure.com/git-for-windows/git/_build/results?buildId=26757
Ciao,
Dscho
> Please include the relevant details in the commit message instead of
> the cover letter.
>
> > Exclude the files in this folder from this conversion.
> >
> > Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> > ---
> > .gitattributes | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/.gitattributes b/.gitattributes
> > index acf853e029..3738cea7eb 100644
> > --- a/.gitattributes
> > +++ b/.gitattributes
> > @@ -13,3 +13,4 @@
> > /Documentation/gitk.txt conflict-marker-size=32
> > /Documentation/user-manual.txt conflict-marker-size=32
> > /t/t????-*.sh conflict-marker-size=32
> > +/t/oid-info/* eol=lf
> > --
> > gitgitgadget
>
^ permalink raw reply
* [PATCH 0/1] Fix regression in t9902 with NO_PERL
From: Johannes Schindelin via GitGitGadget @ 2018-12-13 13:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
The oneline notwithstanding,13374987dd (completion: use _gitcompbuiltin for
format-patch, 2018-11-03) changed also the way send-email options are
completed, by asking the git send-email command itself what options it
offers.
Necessarily, this must fail when built with NO_PERL because send-email
itself is a Perl script. Which means that we need the PERL prerequisite for
the send-email test case in t9902.
Johannes Schindelin (1):
t9902: 'send-email' test case requires PERL
t/t9902-completion.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
base-commit: 5d826e972970a784bd7a7bdf587512510097b8c7
Published-As: https://github.com/gitgitgadget/git/releases/tags/pr-99%2Fdscho%2Ft9902-no-perl-fix-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-99/dscho/t9902-no-perl-fix-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/99
--
gitgitgadget
^ permalink raw reply
* [PATCH 1/1] t9902: 'send-email' test case requires PERL
From: Johannes Schindelin via GitGitGadget @ 2018-12-13 13:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
In-Reply-To: <pull.99.git.gitgitgadget@gmail.com>
From: Johannes Schindelin <johannes.schindelin@gmx.de>
With NO_PERL, the `git send-email` script errors out with code 128,
mentioning that Git was built without Perl support.
Therefore, when the completion tries to ask for possible completions via
`git send-email --git-completion-helper`, it won't provide what is
necessary for that test case to pass.
So let's mark it with the PERL prerequisite.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
t/t9902-completion.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t9902-completion.sh b/t/t9902-completion.sh
index d01ad8eb25..137fdc9bd5 100755
--- a/t/t9902-completion.sh
+++ b/t/t9902-completion.sh
@@ -1539,7 +1539,7 @@ test_expect_success 'complete tree filename with metacharacters' '
EOF
'
-test_expect_success 'send-email' '
+test_expect_success PERL 'send-email' '
test_completion "git send-email --cov" "--cover-letter " &&
test_completion "git send-email ma" "master "
'
--
gitgitgadget
^ permalink raw reply related
* Re: Preparing for 2.20.1 brown-paper-bag maintenance release
From: Johannes Schindelin @ 2018-12-13 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Derrick Stolee, Nguyễn Thái Ngọc Duy
In-Reply-To: <xmqq4lbiey7s.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Thu, 13 Dec 2018, Junio C Hamano wrote:
> * ds/hash-independent-tests-fix (2018-12-12) 1 commit
> - .gitattributes: ensure t/oid-info/* has eol=lf
>
> Test portability fix.
>
> [...]
>
> * js/mailinfo-format-flowed-fix (2018-12-13) 1 commit
> - t4256: mark support files as LF-only
>
> Test portability fix.
We found one more issue that I'd like to get fixed while we're at it:
one test case in t9902 now needs the PERL prerequisite.
Let me coordinate with Stolee who will send this.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC/PATCH] Use mailmap by default in log, show and whatchanged
From: CB Bailey @ 2018-12-13 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <20181213120940.26477-1-cb@hashpling.org>
On Thu, Dec 13, 2018 at 12:09:40PM +0000, CB Bailey wrote:
> I had a dig around in the mailing list archives and couldn't find any
> specific reason not to use a mailmap in log where one is in use. I did
> find this message which suggests that it makes sense to make it the
> default for human-consumed formats. This patch doesn't affect
> "--pretty=raw" formatting.
This week I'm having an issue with sending messages a few seconds before
I've completed them.
This message:
https://public-inbox.org/git/20121112231815.GE10531@sigill.intra.peff.net/
CB
^ permalink raw reply
* [RFC/PATCH] Use mailmap by default in log, show and whatchanged
From: CB Bailey @ 2018-12-13 12:09 UTC (permalink / raw)
To: git
From: CB Bailey <cbailey32@bloomberg.net>
People who have changed their name or email address will usually know
that they need to set 'log.mailmap' in order to have their new details
reflected for old commits with 'git log', but others who interact with
them may not know or care enough to enable this option.
Change the default for 'git log' and friends to always use mailmap so
that everyone gets to see canonical names and email addresses.
Signed-off-by: CB Bailey <cbailey32@bloomberg.net>
---
Related to my patch to make shortlog pass the mailmap into the revision
walker which may end up being configuratble behavior, I thought I'd
propose this for discussion.
For people who change their names during their involvement in a project,
it can be important that the people with whom they work only see their
correct name, even when browsing old history.
I had a dig around in the mailing list archives and couldn't find any
specific reason not to use a mailmap in log where one is in use. I did
find this message which suggests that it makes sense to make it the
default for human-consumed formats. This patch doesn't affect
"--pretty=raw" formatting.
Documentation/config/log.txt | 4 ++--
Documentation/git-log.txt | 12 +++++++++---
builtin/log.c | 2 +-
t/t4203-mailmap.sh | 18 ++++++++++++++++++
4 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/Documentation/config/log.txt b/Documentation/config/log.txt
index 78d9e4453a..8a01eed46b 100644
--- a/Documentation/config/log.txt
+++ b/Documentation/config/log.txt
@@ -39,5 +39,5 @@ log.showSignature::
linkgit:git-whatchanged[1] assume `--show-signature`.
log.mailmap::
- If true, makes linkgit:git-log[1], linkgit:git-show[1], and
- linkgit:git-whatchanged[1] assume `--use-mailmap`.
+ If false, makes linkgit:git-log[1], linkgit:git-show[1], and
+ linkgit:git-whatchanged[1] assume `--no-use-mailmap`.
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 90761f1694..7815c9a6cb 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -50,9 +50,11 @@ OPTIONS
commit was reached.
--use-mailmap::
- Use mailmap file to map author and committer names and email
- addresses to canonical real names and email addresses. See
- linkgit:git-shortlog[1].
+--no-use-mailmap::
+ Use (or don't use) mailmap file to map author and committer names and
+ email addresses to canonical real names and email addresses. The default
+ is to use the mailmap file, but this can be overriden with the
+ `log.mailmap` configuration option. See linkgit:git-shortlog[1].
--full-diff::
Without this flag, `git log -p <path>...` shows commits that
@@ -205,6 +207,10 @@ log.showRoot::
`git log -p` output would be shown without a diff attached.
The default is `true`.
+log.mailmap::
+ If `false`, makes `git log` and related commands assume
+ `--no-use-mailmap`.
+
log.showSignature::
If `true`, `git log` and related commands will act as if the
`--show-signature` option was passed to them.
diff --git a/builtin/log.c b/builtin/log.c
index e8e51068bd..41a5eefb20 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -46,7 +46,7 @@ static int default_follow;
static int default_show_signature;
static int decoration_style;
static int decoration_given;
-static int use_mailmap_config;
+static int use_mailmap_config = 1;
static const char *fmt_patch_subject_prefix = "PATCH";
static const char *fmt_pretty;
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 43b1522ea2..efb145c4cd 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -424,6 +424,24 @@ EOF
test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author >actual &&
+ test_cmp expect actual &&
+# --use-mailmap is the default
+ git log | grep Author >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<\EOF
+Author: CTO <cto@coompany.xx>
+Author: claus <me@company.xx>
+Author: santa <me@company.xx>
+Author: nick2 <nick2@company.xx>
+Author: nick2 <bugs@company.xx>
+Author: nick1 <bugs@company.xx>
+Author: A U Thor <author@example.com>
+EOF
+
+test_expect_success 'Log output with --no-use-mailmap' '
+ git log --no-use-mailmap | grep Author >actual &&
test_cmp expect actual
'
--
2.20.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox