* Re: [PATCHv2 4/5] ok_to_remove_submodule: absorb the submodule git dir
From: Junio C Hamano @ 2016-12-14 18:46 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, David.Turner, bmwill, sandals
In-Reply-To: <20161213205622.841-5-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> It is a major reason to say no, when deciding if a submodule can be
> deleted, if the git directory of the submodule being contained in the
> submodule's working directory.
>
> Migrate the git directory into the superproject instead of failing,
> and proceed with the other checks.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> submodule.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index 2d13744b06..e42efa2337 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1026,11 +1026,22 @@ int ok_to_remove_submodule(const char *path, unsigned flags)
> struct strbuf buf = STRBUF_INIT;
> int ok_to_remove = 1;
>
> + /* Is it there? */
> if (!file_exists(path) || is_empty_dir(path))
> return 1;
>
> - if (!submodule_uses_gitfile(path))
> - return 0;
> + /* Does it have a .git directory? */
> + if (!submodule_uses_gitfile(path)) {
> + absorb_git_dir_into_superproject("", path,
> + ABSORB_GITDIR_RECURSE_SUBMODULES);
> +
> + /*
> + * We should be using a gitfile by now. Let's double
> + * check as losing the git dir would be fatal.
> + */
> + if (!submodule_uses_gitfile(path))
> + return 0;
> + }
It feels a bit funny for a function that answers yes/no question to
actually have a side effect, but probably it is OK. It feels dirty,
but I dunno.
A brief reading of the above makes us wonder what should happen if
the absorb_git_dir_into_superproject() call fails, but a separate
"submodule_uses_gitfile()" is needed to see if it failed? Perhaps
the function needs to tell the caller if it succeeded?
>
> argv_array_pushl(&cp.args, "status", "--porcelain",
> "--ignore-submodules=none", NULL);
^ permalink raw reply
* Re: [PATCHv2 2/5] submodule: modernize ok_to_remove_submodule to use argv_array
From: Junio C Hamano @ 2016-12-14 18:39 UTC (permalink / raw)
To: Stefan Beller; +Cc: git, David.Turner, bmwill, sandals
In-Reply-To: <20161213205622.841-3-sbeller@google.com>
Stefan Beller <sbeller@google.com> writes:
> Instead of constructing the NULL terminated array ourselves, we
> should make use of the argv_array infrastructure.
>
> While at it, adapt the error messages to reflect the actual invocation.
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> submodule.c | 14 ++++----------
> 1 file changed, 4 insertions(+), 10 deletions(-)
Looks good.
>
> diff --git a/submodule.c b/submodule.c
> index 45ccfb7ab4..9f0b544ebe 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1023,13 +1023,6 @@ int ok_to_remove_submodule(const char *path)
> {
> ssize_t len;
> struct child_process cp = CHILD_PROCESS_INIT;
> - const char *argv[] = {
> - "status",
> - "--porcelain",
> - "-u",
> - "--ignore-submodules=none",
> - NULL,
> - };
> struct strbuf buf = STRBUF_INIT;
> int ok_to_remove = 1;
>
> @@ -1039,14 +1032,15 @@ int ok_to_remove_submodule(const char *path)
> if (!submodule_uses_gitfile(path))
> return 0;
>
> - cp.argv = argv;
> + argv_array_pushl(&cp.args, "status", "--porcelain", "-u",
> + "--ignore-submodules=none", NULL);
> prepare_submodule_repo_env(&cp.env_array);
> cp.git_cmd = 1;
> cp.no_stdin = 1;
> cp.out = -1;
> cp.dir = path;
> if (start_command(&cp))
> - die("Could not run 'git status --porcelain -uall --ignore-submodules=none' in submodule %s", path);
> + die(_("could not run 'git status --porcelain -u --ignore-submodules=none' in submodule %s"), path);
>
> len = strbuf_read(&buf, cp.out, 1024);
> if (len > 2)
> @@ -1054,7 +1048,7 @@ int ok_to_remove_submodule(const char *path)
> close(cp.out);
>
> if (finish_command(&cp))
> - die("'git status --porcelain -uall --ignore-submodules=none' failed in submodule %s", path);
> + die(_("'git status --porcelain -u --ignore-submodules=none' failed in submodule %s"), path);
>
> strbuf_release(&buf);
> return ok_to_remove;
^ permalink raw reply
* Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
From: Junio C Hamano @ 2016-12-14 18:04 UTC (permalink / raw)
To: Chris Packham; +Cc: git, mah, peff, jacob.keller
In-Reply-To: <20161214083757.26412-1-judge.packham@gmail.com>
The last one 3/3 is a nice touch that makes sure that we do not
forget what we discovered during the discussion. Very much
appreciated.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH v9 4/5] http: create function to get curl allowed protocols
From: Brandon Williams @ 2016-12-14 18:00 UTC (permalink / raw)
To: Jeff King; +Cc: git, sbeller, bburky, gitster, jrnieder
In-Reply-To: <20161214160330.iqvwxshsgk4n2gm7@sigill.intra.peff.net>
On 12/14, Jeff King wrote:
> On Tue, Dec 13, 2016 at 05:40:36PM -0800, Brandon Williams wrote:
>
> > Move the creation of an allowed protocols whitelist to a helper
> > function.
>
> This is "what" but not "why". You can figure it out if you see the next
> patch, but it's often nice to make a brief mention, like:
>
> This will be useful when we need to compute the set of allowed
> protocols differently for normal and redirect cases.
Commit message writing is hard (at least for me :). I'll update the
message to indicate the why.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH] parse-options: print "fatal:" before usage_msg_opt()
From: Junio C Hamano @ 2016-12-14 17:57 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161214151009.4wdzjb44f6aki5ug@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Programs may use usage_msg_opt() to print a brief message
> followed by the program usage, and then exit. The message
> isn't prefixed at all, though, so it doesn't match our usual
> error output and is easy to overlook:
>
> $ git clone 1 2 3
> Too many arguments.
>
> usage: git clone [<options>] [--] <repo> [<dir>]
>
> -v, --verbose be more verbose
> -q, --quiet be more quiet
> --progress force progress reporting
> -n, --no-checkout don't create a checkout
> --bare create a bare repository
> [...and so on for another 31 lines...]
>
> It looks especially bad when the message starts with an
> option, like:
>
> $ git replace -e
> -e needs exactly one argument
>
> usage: git replace [-f] <object> <replacement>
> or: git replace [-f] --edit <object>
> [...etc...]
>
> Let's put our usual "fatal:" prefix in front of it.
I briefly wondered if any caller uses this in a non-fatal situation,
but usage_with_options() always dies, so this looks like the right
thing to do. Thanks.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Some of the message in git-clone could stand to be rewritten to match
> our usual style, too (no capitals, no trailing period), but that's
> obviously out of scope for this patch. I don't think this change makes
> them look any worse.
>
> parse-options.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/parse-options.c b/parse-options.c
> index 312a85dbd..4fbe924a5 100644
> --- a/parse-options.c
> +++ b/parse-options.c
> @@ -661,7 +661,7 @@ void NORETURN usage_msg_opt(const char *msg,
> const char * const *usagestr,
> const struct option *options)
> {
> - fprintf(stderr, "%s\n\n", msg);
> + fprintf(stderr, "fatal: %s\n\n", msg);
> usage_with_options(usagestr, options);
> }
^ permalink raw reply
* Re: [PATCH v9 3/5] http: always warn if libcurl version is too old
From: Brandon Williams @ 2016-12-14 17:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, sbeller, bburky, gitster, jrnieder
In-Reply-To: <20161214160123.a6a7fve5qz5xgg7n@sigill.intra.peff.net>
On 12/14, Jeff King wrote:
> On Tue, Dec 13, 2016 at 05:40:35PM -0800, Brandon Williams wrote:
>
> > diff --git a/transport.c b/transport.c
> > index e1ba78b..fbd799d 100644
> > --- a/transport.c
> > +++ b/transport.c
> > @@ -700,11 +700,6 @@ void transport_check_allowed(const char *type)
> > die("transport '%s' not allowed", type);
> > }
> >
> > -int transport_restrict_protocols(void)
> > -{
> > - return !!protocol_whitelist();
> > -}
> > -
>
> This function was subtly broken as of patch 2 of the series. It's
> probably not a big deal in the long run, but should the series be
> re-ordered to put this one first?
>
> I think the commit message would need adjusted, but it probably should
> mention the reasons this is a good idea even _without_ the new config
> system. Namely that even when there's no protocol whitelist, newer
> versions of curl have all of the other non-http protocols disabled.
>
> I wonder if anybody is actually using a version of curl old enough to
> trigger this. If so, they're going to get the warning every time they
> fetch via http. We might need to stick it behind an "advice.*" config
> option, though I'm inclined to leave it as-is and see if anybody
> actually complains.
>
> -Peff
Yeah you're right, transport_restrict_protocols() is definitely broken
after patch 2. Since I'm probably going to need to do a reroll based on
some of your comments in the other patches in the series we might as
well reorder patch 2 and 3 so this isn't broken between patches.
--
Brandon Williams
^ permalink raw reply
* Re: [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files
From: Junio C Hamano @ 2016-12-14 17:50 UTC (permalink / raw)
To: Beat Bolli; +Cc: Git List
In-Reply-To: <b137249e-728a-5d3c-4993-5ed5a1593737@drbeat.li>
Beat Bolli <dev+git@drbeat.li> writes:
> On 14.12.16 00:31, Beat Bolli wrote:
>
>> [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files
>
> Dang! And again I'm not capable of putting an underline instead of the
> dash...
>
> Junio, would you please reword the subject to
>
> Re: [PATCH v2 4/6] update_unicode.sh: automatically download newer
> definition files
Will do.
This is an indication that the script is probably named against
people's expectation. We may want to rename it after the dust
settles.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files
From: Beat Bolli @ 2016-12-14 17:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <1481671904-1143-5-git-send-email-dev+git@drbeat.li>
On 14.12.16 00:31, Beat Bolli wrote:
> [PATCH v2 4/6] update-unicode.sh: automatically download newer definition files
Dang! And again I'm not capable of putting an underline instead of the
dash...
Junio, would you please reword the subject to
Re: [PATCH v2 4/6] update_unicode.sh: automatically download newer
definition files
Thanks,
Beat
> we should also download them if a newer version exists on the Unicode
> consortium's servers. Option -N of wget does this nicely for us.
>
> Reviewed-by: Torsten Bögershausen <tboegi@web.de>
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
> contrib/update-unicode/update_unicode.sh | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/update-unicode/update_unicode.sh b/contrib/update-unicode/update_unicode.sh
> index 9f1bf31..56871a1 100755
> --- a/contrib/update-unicode/update_unicode.sh
> +++ b/contrib/update-unicode/update_unicode.sh
> @@ -8,12 +8,8 @@
> cd "$(dirname "$0")"
> UNICODEWIDTH_H=$(git rev-parse --show-toplevel)/unicode_width.h
>
> -if ! test -f UnicodeData.txt; then
> - wget http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt
> -fi &&
> -if ! test -f EastAsianWidth.txt; then
> - wget http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt
> -fi &&
> +wget -N http://www.unicode.org/Public/UCD/latest/ucd/UnicodeData.txt \
> + http://www.unicode.org/Public/UCD/latest/ucd/EastAsianWidth.txt &&
> if ! test -d uniset; then
> git clone https://github.com/depp/uniset.git &&
> ( cd uniset && git checkout 4b186196dd )
>
^ permalink raw reply
* Re: [PATCHv2 0/7] Fix and generalize version sort reordering
From: Junio C Hamano @ 2016-12-14 17:36 UTC (permalink / raw)
To: Jeff King
Cc: SZEDER Gábor, Nguyễn Thái Ngọc Duy,
Leho Kraav, git
In-Reply-To: <20161214170852.bzh5pyl4bov6rwbt@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Dec 08, 2016 at 03:23:54PM +0100, SZEDER Gábor wrote:
>
>> > With my patches it looks like this:
>> >
>> > $ git -c versionsort.prereleasesuffix=-pre \
>> > -c versionsort.prereleasesuffix=-prerelease \
>> > tag -l --sort=version:refname
>> > v1.0.0-prerelease1
>> > v1.0.0-pre1
>> > v1.0.0-pre2
>> > v1.0.0
>>
>> And when there happen to be more than one matching suffixes starting
>> at the same earliest position, then we should pick the longest of
>> them. The new patch 6/7 implements this behavior.
>
> The whole approach taken by the suffix code (before your patches) leaves
> me with the nagging feeling that the comparison is not always going to
> be transitive (i.e., that "a < b && b < c" does not always imply "a <
> c"), which is going to cause nonsensical sorting results.
>
> And that may be part of the issue your 6/7 fixes.
>
> I spent some time playing with this the other day, though, and couldn't
> come up with a specific example that fails the condition above.
>
> It just seems like the whole thing would conceptually easier if we
> pre-parsed the versions into a sequence of elements, then the comparison
> between any two elements would just walk that sequence. The benefit
> there is that you can implement whatever rules you like for the parsing
> (like "prefer longer suffixes to shorter"), but you know the comparison
> will always be consistent.
>
> It would also be more efficient, I think (it seems like the sort is
> O(nr_tags * lg(nr_tags) * nr_suffixes) due to parsing suffixes in the
> comparator). Though that probably doesn't matter much in practice.
>
> I dunno. I think maybe your 6/7 has converged on an equivalent behavior.
> And I am certainly not volunteering to re-write it, so if what you have
> works, I'm not opposed to it.
I also had worries about transitiveness but couldn't break it after
trying for some time. I find your pre-parsing suggestion a great
one, not from the point of view of performance, but because I would
imagine that the resulting logic would become a lot easier to
understand.
^ permalink raw reply
* Re: [PATCH] fix pushing to //server/share/dir paths on Windows
From: Jeff King @ 2016-12-14 17:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <2ff2613c-47da-a780-5d38-93e16cb16328@kdbg.org>
On Tue, Dec 13, 2016 at 10:32:01PM +0100, Johannes Sixt wrote:
> normalize_path_copy() is not prepared to keep the double-slash of a
> //server/share/dir kind of path, but treats it like a regular POSIX
> style path and transforms it to /server/share/dir.
>
> The bug manifests when 'git push //server/share/dir master' is run,
> because tmp_objdir_add_as_alternate() uses the path in normalized
> form when it registers the quarantine object database via
> link_alt_odb_entries(). Needless to say that the directory cannot be
> accessed using the wrongly normalized path.
Thanks for digging this up! I had a feeling that the problem was going
to be in the underlying path code, but I didn't want to just pass the
buck without evidence. :)
> - if (is_dir_sep(*src)) {
> + /*
> + * Handle initial part of absolute path: "/", "C:/", "\\server\share/".
> + */
> + offset = offset_1st_component(src);
> + if (offset) {
> + /* Convert the trailing separator to '/' on Windows. */
> + memcpy(dst, src, offset - 1);
> + dst += offset - 1;
> *dst++ = '/';
Hmm. So this is the "change-of-behavior" bit. Would it be reasonable to
write:
/* Copy initial part of absolute path, converting separators on Windows */
const char *end = src + offset_1st_component(src);
while (src < end) {
char c = *src++;
if (c == '\\')
c = '/';
*dst++ = c;
}
? I'm not sure if it's wrong to convert backslashes in that first
component or not (but certainly we were before). I don't think we'd need
is_dir_sep() in that "if()", because we can leave slashes as-is. But
maybe it would make the code easier to read.
-Peff
^ permalink raw reply
* Re: [PATCHv2 0/7] Fix and generalize version sort reordering
From: Jeff King @ 2016-12-14 17:08 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy, Leho Kraav,
git
In-Reply-To: <20161208142401.1329-1-szeder.dev@gmail.com>
On Thu, Dec 08, 2016 at 03:23:54PM +0100, SZEDER Gábor wrote:
> > With my patches it looks like this:
> >
> > $ git -c versionsort.prereleasesuffix=-pre \
> > -c versionsort.prereleasesuffix=-prerelease \
> > tag -l --sort=version:refname
> > v1.0.0-prerelease1
> > v1.0.0-pre1
> > v1.0.0-pre2
> > v1.0.0
>
> And when there happen to be more than one matching suffixes starting
> at the same earliest position, then we should pick the longest of
> them. The new patch 6/7 implements this behavior.
The whole approach taken by the suffix code (before your patches) leaves
me with the nagging feeling that the comparison is not always going to
be transitive (i.e., that "a < b && b < c" does not always imply "a <
c"), which is going to cause nonsensical sorting results.
And that may be part of the issue your 6/7 fixes.
I spent some time playing with this the other day, though, and couldn't
come up with a specific example that fails the condition above.
It just seems like the whole thing would conceptually easier if we
pre-parsed the versions into a sequence of elements, then the comparison
between any two elements would just walk that sequence. The benefit
there is that you can implement whatever rules you like for the parsing
(like "prefer longer suffixes to shorter"), but you know the comparison
will always be consistent.
It would also be more efficient, I think (it seems like the sort is
O(nr_tags * lg(nr_tags) * nr_suffixes) due to parsing suffixes in the
comparator). Though that probably doesn't matter much in practice.
I dunno. I think maybe your 6/7 has converged on an equivalent behavior.
And I am certainly not volunteering to re-write it, so if what you have
works, I'm not opposed to it.
-Peff
^ permalink raw reply
* Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
From: Junio C Hamano @ 2016-12-14 17:01 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Packham, git, mah, jacob.keller
In-Reply-To: <20161214152039.swtll7xrmcdwz7bc@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So not too bad (and you could probably refactor it to avoid some of the
> duplication). Though it does get some obscure cases wrong, like:
>
> git merge --continue --verbose --quiet
>
> I dunno. Maybe I am leading you down a rabbit hole, and we should just
> live with silently ignoring useless options.
I think you need to handle this in parse-options API if you really
wanted to do this correctly.
<xmqq60mn671x.fsf@gitster.mtv.corp.google.com> may serve as a
reasonable outline for building one.
^ permalink raw reply
* Re: [PATCH v9 5/5] transport: add from_user parameter to is_transport_allowed
From: Jeff King @ 2016-12-14 16:40 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, bburky, gitster, jrnieder
In-Reply-To: <1481679637-133137-6-git-send-email-bmwill@google.com>
On Tue, Dec 13, 2016 at 05:40:37PM -0800, Brandon Williams wrote:
> Add the from_user parameter to the 'is_transport_allowed' function.
> This allows callers to query if a transport protocol is allowed, given
> that the caller knows that the protocol is coming from the user (1) or
> not from the user (0) such as redirects in libcurl. If unknown a -1
> should be provided which falls back to reading `GIT_PROTOCOL_FROM_USER`
> to determine if the protocol came from the user.
I think your commit message is upside-down with respect to the purpose
of the patch. The end goal we want is for http to distinguish between
protocol restrictions for redirects versus initial requests. The rest is
an implementation detail. It's definitely still worth discussing that
implementation detail (though I think your in-code comments may be
sufficient), but I don't see the rationale discussed here at all.
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
> http.c | 14 +++++++-------
> transport.c | 8 +++++---
> transport.h | 13 ++++++++++---
> 3 files changed, 22 insertions(+), 13 deletions(-)
I'm trying to think of a way to test this. I guess the case we are
covering here is when a server redirects, but the protocol is only
allowed from the user. So:
diff --git a/t/t5812-proto-disable-http.sh b/t/t5812-proto-disable-http.sh
index 044cc152f..d911afd24 100755
--- a/t/t5812-proto-disable-http.sh
+++ b/t/t5812-proto-disable-http.sh
@@ -30,5 +30,12 @@ test_expect_success 'curl limits redirects' '
test_must_fail git clone "$HTTPD_URL/loop-redir/smart/repo.git"
'
+test_expect_success 'http can be limited to from-user' '
+ git -c protocol.http.allow=user \
+ clone "$HTTPD_URL/smart/repo.git" plain.git &&
+ test_must_fail git -c protocol.http.allow=user \
+ clone "$HTTPD_URL/smart-redir-perm/repo.git" redir.git
+'
+
stop_httpd
test_done
It's an oddball configuration, and you'd probably just set
http.followRedirects=false in practice, but it does correctly check this
case.
> @@ -588,9 +588,9 @@ static CURL *get_curl_handle(void)
> #endif
> #if LIBCURL_VERSION_NUM >= 0x071304
> curl_easy_setopt(result, CURLOPT_REDIR_PROTOCOLS,
> - get_curl_allowed_protocols());
> + get_curl_allowed_protocols(0));
> curl_easy_setopt(result, CURLOPT_PROTOCOLS,
> - get_curl_allowed_protocols());
> + get_curl_allowed_protocols(-1));
This covers internal redirects done by libcurl, but not the dumb-walker
http-alternates nonsense. We have to feed the URL from http-alternates
back to curl ourselves, so it uses CURLOPT_PROTOCOLS even though it
should count as "not from the user".
To fix that, I think we'd need something like:
- get_curl_handle() stops setting these options, as it is done only
once when the curl handle is initialized. Instead, the protocol
restrictions should go into get_active_slot(), which is called for
each request. The values set would remain the same, and be the
baseline.
- the http-walker.c code would need to know when it's requesting from
the base URL, and when it's an alternate. I think this would depend
on the position of the "alt" in in the linked list it keeps.
- when requesting from an alternate, http-walker would set
CURLOPT_PROTOCOLS with get_curl_allowed_protocols(0)
I have to admit that it sounds like a fair bit of work for a pretty
obscure case. You'd have to:
1. Turn http.allowRedirects to "true", to allow redirects even for
non-initial contact.
2. Turn one of protocol.{http,https,ftp,ftps}.allow to "user" to
restrict it from being used in a redirect.
I'm tempted to punt on it and just do:
if (http_follow_config == HTTP_FOLLOW_ALWAYS &&
get_curl_allowed_protocols(0) != get_curl_allowed_protocols(-1))
die("user-only protocol restrictions not implemented for http-alternates");
which errs on the safe side. We could even shove that down into the case
where we actually see some alternates, like:
diff --git a/http-walker.c b/http-walker.c
index c2f81cd6a..5bcc850b1 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -160,6 +160,12 @@ static void prefetch(struct walker *walker, unsigned char *sha1)
#endif
}
+static void check_alternates_protocol_restrictions(void)
+{
+ if (get_curl_allowed_protocols(0) != get_curl_allowed_protocol(-1))
+ die("user-only protocol restrictions not implemented for http alternates");
+}
+
static void process_alternates_response(void *callback_data)
{
struct alternates_request *alt_req =
@@ -272,6 +278,7 @@ static void process_alternates_response(void *callback_data)
/* skip "objects\n" at end */
if (okay) {
struct strbuf target = STRBUF_INIT;
+ check_alternates_protocol_restrictions();
strbuf_add(&target, base, serverlen);
strbuf_add(&target, data + i, posn - i - 7);
warning("adding alternate object store: %s",
I find it unlikely that anybody would ever care, but at least we'd do
the safe thing. I dunno. Maybe I am just being lazy.
-Peff
^ permalink raw reply related
* Re: [PATCH v9 4/5] http: create function to get curl allowed protocols
From: Jeff King @ 2016-12-14 16:03 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, bburky, gitster, jrnieder
In-Reply-To: <1481679637-133137-5-git-send-email-bmwill@google.com>
On Tue, Dec 13, 2016 at 05:40:36PM -0800, Brandon Williams wrote:
> Move the creation of an allowed protocols whitelist to a helper
> function.
This is "what" but not "why". You can figure it out if you see the next
patch, but it's often nice to make a brief mention, like:
This will be useful when we need to compute the set of allowed
protocols differently for normal and redirect cases.
-Peff
^ permalink raw reply
* Re: [PATCH v9 3/5] http: always warn if libcurl version is too old
From: Jeff King @ 2016-12-14 16:01 UTC (permalink / raw)
To: Brandon Williams; +Cc: git, sbeller, bburky, gitster, jrnieder
In-Reply-To: <1481679637-133137-4-git-send-email-bmwill@google.com>
On Tue, Dec 13, 2016 at 05:40:35PM -0800, Brandon Williams wrote:
> diff --git a/transport.c b/transport.c
> index e1ba78b..fbd799d 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -700,11 +700,6 @@ void transport_check_allowed(const char *type)
> die("transport '%s' not allowed", type);
> }
>
> -int transport_restrict_protocols(void)
> -{
> - return !!protocol_whitelist();
> -}
> -
This function was subtly broken as of patch 2 of the series. It's
probably not a big deal in the long run, but should the series be
re-ordered to put this one first?
I think the commit message would need adjusted, but it probably should
mention the reasons this is a good idea even _without_ the new config
system. Namely that even when there's no protocol whitelist, newer
versions of curl have all of the other non-http protocols disabled.
I wonder if anybody is actually using a version of curl old enough to
trigger this. If so, they're going to get the warning every time they
fetch via http. We might need to stick it behind an "advice.*" config
option, though I'm inclined to leave it as-is and see if anybody
actually complains.
-Peff
^ permalink raw reply
* Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'
From: Jeff King @ 2016-12-14 15:20 UTC (permalink / raw)
To: Chris Packham; +Cc: git, mah, jacob.keller, gitster
In-Reply-To: <20161214083757.26412-1-judge.packham@gmail.com>
On Wed, Dec 14, 2016 at 09:37:55PM +1300, Chris Packham wrote:
> + if (continue_current_merge) {
> + int nargc = 1;
> + const char *nargv[] = {"commit", NULL};
> +
> + if (orig_argc != 2)
> + usage_msg_opt("--continue expects no arguments",
> + builtin_merge_usage, builtin_merge_options);
This message should probably be inside a _() for translation.
I noticed when running it that the output looks funny:
$ git merge --continue foo
--continue expects no arguments
usage: [...]
I was going to suggest adding something like "fatal:" here, but I
actually think it should be the responsibility of usage_msg_opt().
Looking at its other callers, they would all benefit. I posted a
patch:
http://public-inbox.org/git/20161214151009.4wdzjb44f6aki5ug@sigill.intra.peff.net/
I also wondered what it would look like to support "--quiet" on top of
this. I don't care that much about it in particular, but I just want to
make sure we're not painting ourselves into a corner.
Here's what I came up with;
diff --git a/builtin/merge.c b/builtin/merge.c
index 668aaffb8..b13523ce9 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1160,10 +1160,16 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
show_progress = 0;
if (abort_current_merge) {
- int nargc = 2;
- const char *nargv[] = {"reset", "--merge", NULL};
+ int acceptable_arguments = 2; /* argv[0] plus --abort */
+ struct argv_array nargv = ARGV_ARRAY_INIT;
- if (orig_argc != 2)
+ argv_array_pushl(&nargv, "reset", "--merge", NULL);
+ if (verbosity < 0) {
+ acceptable_arguments++;
+ argv_array_push(&nargv, "--quiet");
+ }
+
+ if (orig_argc != acceptable_arguments)
usage_msg_opt("--abort expects no arguments",
builtin_merge_usage, builtin_merge_options);
@@ -1171,15 +1177,22 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
die(_("There is no merge to abort (MERGE_HEAD missing)."));
/* Invoke 'git reset --merge' */
- ret = cmd_reset(nargc, nargv, prefix);
+ ret = cmd_reset(nargv.argc, nargv.argv, prefix);
+ argv_array_clear(&nargv);
goto done;
}
if (continue_current_merge) {
- int nargc = 1;
- const char *nargv[] = {"commit", NULL};
+ int acceptable_arguments = 2; /* argv[0] plus --abort */
+ struct argv_array nargv = ARGV_ARRAY_INIT;
+
+ argv_array_push(&nargv, "commit");
+ if (verbosity < 0) {
+ acceptable_arguments++;
+ argv_array_push(&nargv, "--quiet");
+ }
- if (orig_argc != 2)
+ if (orig_argc != acceptable_arguments)
usage_msg_opt("--continue expects no arguments",
builtin_merge_usage, builtin_merge_options);
@@ -1187,7 +1200,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
die(_("There is no merge in progress (MERGE_HEAD missing)."));
/* Invoke 'git commit' */
- ret = cmd_commit(nargc, nargv, prefix);
+ ret = cmd_commit(nargv.argc, nargv.argv, prefix);
+ argv_array_clear(&nargv);
goto done;
}
So not too bad (and you could probably refactor it to avoid some of the
duplication). Though it does get some obscure cases wrong, like:
git merge --continue --verbose --quiet
I dunno. Maybe I am leading you down a rabbit hole, and we should just
live with silently ignoring useless options. I looked at what
cherry-pick does for this case, and its verify_opt_compatible is
somewhat scary from a maintenance standpoint. It's a whitelist, not a
blacklist, so it's easy to forget options (and it looks like "git
cherry-pick --abort -Sfoo" is missed, for example).
-Peff
^ permalink raw reply related
* [PATCH] parse-options: print "fatal:" before usage_msg_opt()
From: Jeff King @ 2016-12-14 15:10 UTC (permalink / raw)
To: git
Programs may use usage_msg_opt() to print a brief message
followed by the program usage, and then exit. The message
isn't prefixed at all, though, so it doesn't match our usual
error output and is easy to overlook:
$ git clone 1 2 3
Too many arguments.
usage: git clone [<options>] [--] <repo> [<dir>]
-v, --verbose be more verbose
-q, --quiet be more quiet
--progress force progress reporting
-n, --no-checkout don't create a checkout
--bare create a bare repository
[...and so on for another 31 lines...]
It looks especially bad when the message starts with an
option, like:
$ git replace -e
-e needs exactly one argument
usage: git replace [-f] <object> <replacement>
or: git replace [-f] --edit <object>
[...etc...]
Let's put our usual "fatal:" prefix in front of it.
Signed-off-by: Jeff King <peff@peff.net>
---
Some of the message in git-clone could stand to be rewritten to match
our usual style, too (no capitals, no trailing period), but that's
obviously out of scope for this patch. I don't think this change makes
them look any worse.
parse-options.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/parse-options.c b/parse-options.c
index 312a85dbd..4fbe924a5 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -661,7 +661,7 @@ void NORETURN usage_msg_opt(const char *msg,
const char * const *usagestr,
const struct option *options)
{
- fprintf(stderr, "%s\n\n", msg);
+ fprintf(stderr, "fatal: %s\n\n", msg);
usage_with_options(usagestr, options);
}
--
2.11.0.341.g202cd3142
^ permalink raw reply related
* Re: git stash filename - stashing single files.
From: Paul Smith @ 2016-12-14 15:00 UTC (permalink / raw)
To: Jeff King, Jonas Hartmann; +Cc: git
In-Reply-To: <20161214144444.k4v64accedl6xvho@sigill.intra.peff.net>
On Wed, 2016-12-14 at 09:44 -0500, Jeff King wrote:
> Personally, I think this is a pretty terrible interface. Besides the
> fact that I have never written a stash message in all my years of using
> git, it's totally inconsistent with the rest of git (which would use
> "-m" for the message, and treat arguments as pathspecs).
I agree that this is a terrible (and inconsistent) interface and I would
love to see it changed.
I do use messages on stashes all the time (because I can never remember
their context a week later without a hint--just looking at the diff is
not enough for me) but I would welcome this change. Definitely the
first step would be introducing the "-m" option so people and tools
could begin the switch to using it.
^ permalink raw reply
* Re: [RFC/PATCHv2] Makefile: add cppcheck target
From: Jeff King @ 2016-12-14 14:46 UTC (permalink / raw)
To: Chris Packham; +Cc: git, stefan.naewe, gitter.spiros
In-Reply-To: <20161214112401.mq3n5kui5eeebdtk@sigill.intra.peff.net>
On Wed, Dec 14, 2016 at 06:24:01AM -0500, Jeff King wrote:
> On Wed, Dec 14, 2016 at 10:27:31PM +1300, Chris Packham wrote:
>
> > Changes in v2:
> > - only run over actual git source files.
> > - omit any files in t/
>
> I actually wonder if FIND_SOURCE_FILES should be taking care of the "t/"
> thing. I think "make tags" finds tags in t4051/appended1.c, which is
> just silly.
I just posted a series[1] that should improve things there. But be aware
that it _also_ adds in shell scripts to the result. So you'd maybe want
to pipe the result through "grep -v '\.sh'" for cppcheck.
-Peff
[1] http://public-inbox.org/git/20161214142533.svktxk63eiwaaeor@sigill.intra.peff.net/t/#u
^ permalink raw reply
* Re: git stash filename - stashing single files.
From: Jeff King @ 2016-12-14 14:44 UTC (permalink / raw)
To: Jonas Hartmann; +Cc: git
In-Reply-To: <b528e23b-c763-846e-4040-504a58b690fd@ht-studios.de>
On Wed, Dec 14, 2016 at 02:53:20PM +0100, Jonas Hartmann wrote:
> http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833
>
> Could it be possible to have "git stash [filename][filename]...", to
> stash only single files?
> There seems to be a broad community desire.
I think this would be useful. You can pick and choose with "git stash
-p", but I have still often wanted "git stash -p [filename]".
There is one problem, though: any non-option arguments to "git stash
save" are interpreted as the stash message. So just:
git stash save file
would break backwards compatibility. Annoyingly, so would:
git stash save -- file
which uses the "--" to let you have a message which starts with a dash.
Personally, I think this is a pretty terrible interface. Besides the
fact that I have never written a stash message in all my years of using
git, it's totally inconsistent with the rest of git (which would use
"-m" for the message, and treat arguments as pathspecs).
So it might be worth changing, but we'd probably have to deal with the
backwards compatibility fallout, have a deprecation period, etc.
As for "git stash" without "save", there is magic to rewrite:
git stash [opts]
into
git stash save [opts]
but it explicitly does not allow non-option arguments. So:
git stash foo
is an error (and not unreasonably, since "git stash list" creates an
ambiguity problem). Perhaps:
git stash -- foo
could be allowed to treat "foo" as a filename. There wouldn't be any
backwards compatibility problems, though it would be weird and
inconsistent to be able to specify filenames via the "shortcut"
invocation, but not with "git stash save".
-Peff
^ permalink raw reply
* [PATCH 4/4] Makefile: exclude contrib from FIND_SOURCE_FILES
From: Jeff King @ 2016-12-14 14:32 UTC (permalink / raw)
To: git; +Cc: Chris Packham
In-Reply-To: <20161214142533.svktxk63eiwaaeor@sigill.intra.peff.net>
When you're working on the git project, you're unlikely to
care about random bits in contrib/ (e.g., you would not want
to jump to the copy of xmalloc in the wincred credential
helper). Nobody has really complained because there are
relatively few C files in contrib.
Now that we're matching shell scripts, too, we get quite a
few more hits, especially in the obsolete contrib/examples
directory. Looking for usage() should turn up the one in
git-sh-setup, not in some long-dead version of git-clone.
Let's just exclude all of contrib. Any specific projects
there which are big enough to want tags can generate them
separately.
Signed-off-by: Jeff King <peff@peff.net>
---
Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Makefile b/Makefile
index ef8de4a75..76267262c 100644
--- a/Makefile
+++ b/Makefile
@@ -2154,10 +2154,12 @@ FIND_SOURCE_FILES = ( \
'*.[hcS]' \
'*.sh' \
':!*[tp][0-9][0-9][0-9][0-9]*' \
+ ':!contrib' \
2>/dev/null || \
$(FIND) . \
\( -name .git -type d -prune \) \
-o \( -name '[tp][0-9][0-9][0-9][0-9]*' -prune \) \
+ -o \( -name contrib -type d -prune \) \
-o \( -name build -type d -prune \) \
-o \( -name 'trash*' -type d -prune \) \
-o \( -name '*.[hcS]' -type f -print \) \
--
2.11.0.341.g202cd3142
^ permalink raw reply related
* [PATCH 3/4] Makefile: match shell scripts in FIND_SOURCE_FILES
From: Jeff King @ 2016-12-14 14:29 UTC (permalink / raw)
To: git; +Cc: Chris Packham
In-Reply-To: <20161214142533.svktxk63eiwaaeor@sigill.intra.peff.net>
We feed FIND_SOURCE_FILES to ctags to help developers
navigate to particular functions, but we only feed C source
code. The same feature can be helpful when working with
shell scripts (especially the test suite). Modern versions
of ctags know how to parse shell scripts; we just need to
feed the filenames to it.
This patch specifically avoids including the individual test
scripts themselves. Those are unlikely to be of interest,
and there are a lot of them to process. It does pick up
test-lib.sh and test-lib-functions.sh.
Note that our negative pathspec already excludes the
individual scripts for the ls-files case, but we need to
loosen the `find` rule to match it.
Signed-off-by: Jeff King <peff@peff.net>
---
Maybe people would find this annoying. It does increase the number of
entries in the tags file. I've been running something like it for a few
months and have found it useful.
It's also possible that some people have a version of ctags or etags
that doesn't handle shell scripts. I imagine few enough people actually
run "make tags" in the first place that we can probably try it and see.
Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 001126931..ef8de4a75 100644
--- a/Makefile
+++ b/Makefile
@@ -2152,14 +2152,16 @@ po/build/locale/%/LC_MESSAGES/git.mo: po/%.po
FIND_SOURCE_FILES = ( \
git ls-files \
'*.[hcS]' \
+ '*.sh' \
':!*[tp][0-9][0-9][0-9][0-9]*' \
2>/dev/null || \
$(FIND) . \
\( -name .git -type d -prune \) \
- -o \( -name '[tp][0-9][0-9][0-9][0-9]' -type d -prune \) \
+ -o \( -name '[tp][0-9][0-9][0-9][0-9]*' -prune \) \
-o \( -name build -type d -prune \) \
-o \( -name 'trash*' -type d -prune \) \
-o \( -name '*.[hcS]' -type f -print \) \
+ -o \( -name '*.sh' -type f -print \) \
)
$(ETAGS_TARGET): FORCE
--
2.11.0.341.g202cd3142
^ permalink raw reply related
* [PATCH 2/4] Makefile: exclude test cruft from FIND_SOURCE_FILES
From: Jeff King @ 2016-12-14 14:28 UTC (permalink / raw)
To: git; +Cc: Chris Packham
In-Reply-To: <20161214142533.svktxk63eiwaaeor@sigill.intra.peff.net>
The test directory may contain three types of files that
match our patterns:
1. Helper programs in t/helper.
2. Sample data files (e.g., t/t4051/hello.c).
3. Untracked cruft in trash directories and t/perf/build.
We want to match (1), but not the other two, as they just
clutter up the list.
For the ls-files method, we can drop (2) with a negative
pathspec. We do not have to care about (3), since ls-files
will not list untracked files.
For `find`, we can match both cases with `-prune` patterns.
Signed-off-by: Jeff King <peff@peff.net>
---
I expected that:
':![tp][0-9][0-9][0-9][0-9]'
would work, but it doesn't. I think because we don't match intermediate
directories against pathspecs. So you have to use wildcards to match the
rest of the path.
Makefile | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index f42b1953d..001126931 100644
--- a/Makefile
+++ b/Makefile
@@ -2150,9 +2150,15 @@ po/build/locale/%/LC_MESSAGES/git.mo: po/%.po
$(QUIET_MSGFMT)mkdir -p $(dir $@) && $(MSGFMT) -o $@ $<
FIND_SOURCE_FILES = ( \
- git ls-files '*.[hcS]' 2>/dev/null || \
+ git ls-files \
+ '*.[hcS]' \
+ ':!*[tp][0-9][0-9][0-9][0-9]*' \
+ 2>/dev/null || \
$(FIND) . \
\( -name .git -type d -prune \) \
+ -o \( -name '[tp][0-9][0-9][0-9][0-9]' -type d -prune \) \
+ -o \( -name build -type d -prune \) \
+ -o \( -name 'trash*' -type d -prune \) \
-o \( -name '*.[hcS]' -type f -print \) \
)
--
2.11.0.341.g202cd3142
^ permalink raw reply related
* [PATCH 1/4] Makefile: reformat FIND_SOURCE_FILES
From: Jeff King @ 2016-12-14 14:26 UTC (permalink / raw)
To: git; +Cc: Chris Packham
In-Reply-To: <20161214142533.svktxk63eiwaaeor@sigill.intra.peff.net>
As we add to this in future commits, the formatting is going
to make it harder and harder to read. Let's write it more as
we would in a shell script, putting each logical block on
its own line.
Signed-off-by: Jeff King <peff@peff.net>
---
Just to make the other patches easier to read; no behavior change
intended.
I was tempted to actually pull this out into its own
find-source-files.sh script. I don't know if that is
preferable or not; it certainly makes the "make tags"
output less ugly.
Makefile | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index f53fcc90d..f42b1953d 100644
--- a/Makefile
+++ b/Makefile
@@ -2149,9 +2149,12 @@ endif
po/build/locale/%/LC_MESSAGES/git.mo: po/%.po
$(QUIET_MSGFMT)mkdir -p $(dir $@) && $(MSGFMT) -o $@ $<
-FIND_SOURCE_FILES = ( git ls-files '*.[hcS]' 2>/dev/null || \
- $(FIND) . \( -name .git -type d -prune \) \
- -o \( -name '*.[hcS]' -type f -print \) )
+FIND_SOURCE_FILES = ( \
+ git ls-files '*.[hcS]' 2>/dev/null || \
+ $(FIND) . \
+ \( -name .git -type d -prune \) \
+ -o \( -name '*.[hcS]' -type f -print \) \
+ )
$(ETAGS_TARGET): FORCE
$(RM) $(ETAGS_TARGET)
--
2.11.0.341.g202cd3142
^ permalink raw reply related
* [PATCH 0/4] "make tags" improvements
From: Jeff King @ 2016-12-14 14:25 UTC (permalink / raw)
To: git; +Cc: Chris Packham
A discussion earlier today made me notice that our "make tags" target
includes some cruft that we shouldn't be indexing. This fixes that, and
starts indexing some of the shell scripts, which is something I've been
doing in a hacky way for a while. It's very convenient when working on
the test suite (especially because I can never remember which functions
are declared in test-lib.sh, and which in test-lib-functions.sh).
[1/4]: Makefile: reformat FIND_SOURCE_FILES
[2/4]: Makefile: exclude test cruft from FIND_SOURCE_FILES
[3/4]: Makefile: match shell scripts in FIND_SOURCE_FILES
[4/4]: Makefile: exclude contrib from FIND_SOURCE_FILES
Makefile | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
-Peff
^ permalink raw reply
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