* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Jonathan Nieder @ 2013-01-28 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7vfw1lug6f.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>> Andrej Andb wrote:
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -2068,7 +2068,7 @@ sub picon_url {
>>> if (!$avatar_cache{$email}) {
>>> my ($user, $domain) = split('@', $email);
>>> $avatar_cache{$email} =
>>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
[...]
> Intuitively it feels strange that the above lets the site that gave
> you the base URL dictate over what scheme sites unrelated to it has
> to serve their resources.
The main effect is to slightly improve privacy. A man in the middle
can still see the size of avatars and when you fetched them, but at
least this way when you are using HTTPS they do not see the names of
authors of commits you are looking at.
It also avoids a mixed content warning.
On the other hand, it hurts caching by proxies.
Jonathan
^ permalink raw reply
* Re: [PATCH v2 0/4] Auto-generate mergetool lists
From: John Keeping @ 2013-01-28 22:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Aguilar, git
In-Reply-To: <7vk3qxugdg.fsf@alter.siamese.dyndns.org>
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
> What are the situations where a valid user-defined tools is
> unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval -- "set -- $(git config mergetool.$tool.cmd); echo \"$1\"")
(it's slightly more complicated due to handling difftool.$tool.cmd as
well, but that's essentially it). Then it just uses the same "type
$cmd" test as for built-in tools.
I don't know if there's a better way to extract the first word, but
that's the best I've come up with so far.
John
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Junio C Hamano @ 2013-01-28 22:29 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <20130128221026.GE7759@google.com>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Junio C Hamano wrote:
>>> Andrej Andb wrote:
>
>>>> --- a/gitweb/gitweb.perl
>>>> +++ b/gitweb/gitweb.perl
>>>> @@ -2068,7 +2068,7 @@ sub picon_url {
>>>> if (!$avatar_cache{$email}) {
>>>> my ($user, $domain) = split('@', $email);
>>>> $avatar_cache{$email} =
>>>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
> [...]
>> Intuitively it feels strange that the above lets the site that gave
>> you the base URL dictate over what scheme sites unrelated to it has
>> to serve their resources.
>
> The main effect is to slightly improve privacy. A man in the middle
> can still see the size of avatars and when you fetched them, but at
> least this way when you are using HTTPS they do not see the names of
> authors of commits you are looking at.
>
> It also avoids a mixed content warning.
>
> On the other hand, it hurts caching by proxies.
I am sure mixed content warning was the primary motivation of the
patch. Do we know these external sites actually server what we want
over https://?
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Андрей Баранов @ 2013-01-28 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v7gmxuekl.fsf@alter.siamese.dyndns.org>
Or maybe option like:
/etc/gitweb.conf:
$feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
but it's hard for me :) i don't know perl
2013/1/29 Junio C Hamano <gitster@pobox.com>:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>>> Andrej Andb wrote:
>>
>>>>> --- a/gitweb/gitweb.perl
>>>>> +++ b/gitweb/gitweb.perl
>>>>> @@ -2068,7 +2068,7 @@ sub picon_url {
>>>>> if (!$avatar_cache{$email}) {
>>>>> my ($user, $domain) = split('@', $email);
>>>>> $avatar_cache{$email} =
>>>>> - "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>>>>> + "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
>> [...]
>>> Intuitively it feels strange that the above lets the site that gave
>>> you the base URL dictate over what scheme sites unrelated to it has
>>> to serve their resources.
>>
>> The main effect is to slightly improve privacy. A man in the middle
>> can still see the size of avatars and when you fetched them, but at
>> least this way when you are using HTTPS they do not see the names of
>> authors of commits you are looking at.
>>
>> It also avoids a mixed content warning.
>>
>> On the other hand, it hurts caching by proxies.
>
> I am sure mixed content warning was the primary motivation of the
> patch. Do we know these external sites actually server what we want
> over https://?
>
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Jonathan Nieder @ 2013-01-28 22:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrej Andb, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v7gmxuekl.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I am sure mixed content warning was the primary motivation of the
> patch.
Sure, but that's not enough motivation for me to like it. ;-)
The privacy aspect is enough to motivate it for me.
> Do we know these external sites actually server what we want
> over https://?
Yep. cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi and
www.gravatar.com/avatar both support https and return the expected
responses for queries over https.
^ permalink raw reply
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Junio C Hamano @ 2013-01-28 23:08 UTC (permalink / raw)
To: Андрей Баранов
Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <CAJjU7bQtgaV1XBeeGnuwtz8m3bDtmRYxQE-QasWkoGHNb_NPjQ@mail.gmail.com>
Андрей Баранов <admin@andrej-andb.ru> writes:
> Or maybe option like:
> /etc/gitweb.conf:
> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>
> but it's hard for me :) i don't know perl
The effect is the same and your original patch is shorter and
cleaner to see what is going on; as far as the patch text is
concerned, the original one is just fine.
Except that we wanted a bit more stuff before "---" line. How about
something like this?
Subject: [PATCH] gitweb: refer to picon/gravatar images over the same scheme
The images from picon and gravatar are always used over
http://, and browsers give mixed contents warning when
gitweb is served over https://.
Just drop the scheme: part from the URL, so that these
external sites are accessed over https:// in such a case.
Signed-off-by: Your Name <your@addre.ss>
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
...
^ permalink raw reply
* [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Andrej E Baranov @ 2013-01-28 23:41 UTC (permalink / raw)
To: git; +Cc: gitster, jrnieder, giuseppe.bilotta, jnareb, Andrej E Baranov
Just drop the scheme: part from the URL, so that these
external sites are accessed over https:// in such a case.
Signed-off-by: Andrej E Baranov <admin@andrej-andb.ru>
---
gitweb/gitweb.perl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c6bafe6..1309196 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2068,7 +2068,7 @@ sub picon_url {
if (!$avatar_cache{$email}) {
my ($user, $domain) = split('@', $email);
$avatar_cache{$email} =
- "http://www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
+ "//www.cs.indiana.edu/cgi-pub/kinzler/piconsearch.cgi/" .
"$domain/$user/" .
"users+domains+unknown/up/single";
}
@@ -2083,7 +2083,7 @@ sub gravatar_url {
my $email = lc shift;
my $size = shift;
$avatar_cache{$email} ||=
- "http://www.gravatar.com/avatar/" .
+ "//www.gravatar.com/avatar/" .
Digest::MD5::md5_hex($email) . "?s=";
return $avatar_cache{$email} . $size;
}
--
1.8.1.1
^ permalink raw reply related
* Re: [PATCH] remove protocol from gravatar and picon links for clear if Gitweb is being called through a secure server
From: Андрей Баранов @ 2013-01-28 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git, Giuseppe Bilotta, Jakub Narebski
In-Reply-To: <7v38xkvrbc.fsf@alter.siamese.dyndns.org>
re sended. Very big thanks for example :D
2013/1/29 Junio C Hamano <gitster@pobox.com>:
> Андрей Баранов <admin@andrej-andb.ru> writes:
>
>> Or maybe option like:
>> /etc/gitweb.conf:
>> $feature{'ssl'}{'default'} = ['allways']; ['auto']; ['none'];
>>
>> but it's hard for me :) i don't know perl
>
> The effect is the same and your original patch is shorter and
> cleaner to see what is going on; as far as the patch text is
> concerned, the original one is just fine.
>
> Except that we wanted a bit more stuff before "---" line. How about
> something like this?
>
> Subject: [PATCH] gitweb: refer to picon/gravatar images over the same scheme
>
> The images from picon and gravatar are always used over
> http://, and browsers give mixed contents warning when
> gitweb is served over https://.
>
> Just drop the scheme: part from the URL, so that these
> external sites are accessed over https:// in such a case.
>
> Signed-off-by: Your Name <your@addre.ss>
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> ...
>
^ permalink raw reply
* [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
So this is the second round, unifying the handling of "hidden refs"
a hosting site administrator may want to handle differently from
normal refs available to upload-pack and receive-pack. Big thanks
to Peff for making me realize that what is shown to "git push"
should match what is shown to "git fetch/clone".
The configuration variable has been changed to "transfer.hiderefs"
in this round. I picked refs.[ch] as the shared location to place
the machinery that deals with this configuration, but I am not proud
of the choice---there may be a more suitable place.
The third patch is new; it prevents a hidden ref to be deleted or
updated via "git push" to ensure that its contents are controlled
only from the server side using some side channel (e.g. pull-request
UI on the Web).
There is no "git fetch $there $exact_sha1_obtained_out_of_band"
yet; that must come next, together with a mechanism to control the
availability of it on the server side.
For those who missed it, the first round starts at
http://thread.gmane.org/gmane.comp.version-control.git/213951
Junio C Hamano (3):
upload-pack: share more code
upload-pack: allow hiding ref hiearchies
receive-pack: reject an attempt to update/delete a hidden ref
Documentation/config.txt | 9 +++++++++
builtin/receive-pack.c | 24 +++++++++++++++++++++++
refs.c | 41 +++++++++++++++++++++++++++++++++++++++
refs.h | 3 +++
t/t5512-ls-remote.sh | 9 +++++++++
t/t5516-fetch-push.sh | 24 +++++++++++++++++++++++
upload-pack.c | 50 ++++++++++++++++++++++++++++++++----------------
7 files changed, 144 insertions(+), 16 deletions(-)
--
1.8.1.2.548.g0e4986f
^ permalink raw reply
* [PATCH v2 1/3] upload-pack: share more code
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
upload-pack.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (!(o->flags & OUR_REF)) {
+ o->flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
* [PATCH v2 2/3] upload-pack: allow hiding ref hiearchies
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typical use case may be
[uploadPack]
hiderefs = refs/changes
Note that the underlying protocol still allows a request to fetch
objects at the tip of any ref, including the hidden ones, but on the
client side (e.g. fetch-pack), the requests are checked against the
ls-remote response, so it cannot ask for refs/changes/14/432432, or
for the object name (which is what eventually goes over the wire on
"want" line) the user may obtain out of band (e.g. Gerrit dashboard).
A new capability "allow-tip-sha1-in-want" is returned by upload-pack
to signal updated clients that it may be OK to ask for objects that
were not advertised.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 8 ++++++++
builtin/receive-pack.c | 8 ++++++++
refs.c | 41 +++++++++++++++++++++++++++++++++++++++++
refs.h | 3 +++
t/t5512-ls-remote.sh | 9 +++++++++
upload-pack.c | 25 +++++++++++++++++++++++--
6 files changed, 92 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ef45c99..8e2853e 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2057,6 +2057,14 @@ transfer.fsckObjects::
not set, the value of this variable is used instead.
Defaults to false.
+transfer.hiderefs::
+ String(s) `upload-pack` and `receive-pack` use to decide
+ which refs to omit from their initial advertisement. Use
+ more than one transfer.hiderefs configuration variables to
+ specify multiple prefix strings. A ref that has one of these
+ strings as its prefix is excluded, and is hidden from
+ `git clone --mirror` and `git push :`.
+
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index ff781fe..5ed40be 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -59,6 +59,11 @@ static enum deny_action parse_deny_action(const char *var, const char *value)
static int receive_pack_config(const char *var, const char *value, void *cb)
{
+ int status = parse_hide_refs_config(var, value, cb);
+
+ if (status)
+ return status;
+
if (strcmp(var, "receive.denydeletes") == 0) {
deny_deletes = git_config_bool(var, value);
return 0;
@@ -119,6 +124,9 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
static void show_ref(const char *path, const unsigned char *sha1)
{
+ if (ref_is_hidden(path))
+ return;
+
if (sent_capabilities)
packet_write(1, "%s %s\n", sha1_to_hex(sha1), path);
else
diff --git a/refs.c b/refs.c
index 541fec2..e3574ca 100644
--- a/refs.c
+++ b/refs.c
@@ -3,6 +3,7 @@
#include "object.h"
#include "tag.h"
#include "dir.h"
+#include "string-list.h"
/*
* Make sure "ref" is something reasonable to have under ".git/refs/";
@@ -2556,3 +2557,43 @@ char *shorten_unambiguous_ref(const char *refname, int strict)
free(short_name);
return xstrdup(refname);
}
+
+static struct string_list *hide_refs;
+
+int parse_hide_refs_config(const char *var, const char *value, void *unused)
+{
+ if (!strcmp("transfer.hiderefs", var)) {
+ char *ref;
+ int len;
+
+ if (!value)
+ return config_error_nonbool(var);
+ ref = xstrdup(value);
+ len = strlen(ref);
+ while (len && ref[len - 1] == '/')
+ ref[--len] = '\0';
+ if (!hide_refs) {
+ hide_refs = xcalloc(1, sizeof(*hide_refs));
+ hide_refs->strdup_strings = 1;
+ }
+ string_list_append(hide_refs, ref);
+ }
+ return 0;
+}
+
+int ref_is_hidden(const char *refname)
+{
+ struct string_list_item *item;
+
+ if (!hide_refs)
+ return 0;
+ for_each_string_list_item(item, hide_refs) {
+ int len;
+ if (prefixcmp(refname, item->string))
+ continue;
+ len = strlen(item->string);
+ if (!refname[len] || refname[len] == '/')
+ return 1;
+ }
+ return 0;
+}
diff --git a/refs.h b/refs.h
index d6c2fe2..50b233f 100644
--- a/refs.h
+++ b/refs.h
@@ -147,4 +147,7 @@ int update_ref(const char *action, const char *refname,
const unsigned char *sha1, const unsigned char *oldval,
int flags, enum action_on_err onerr);
+extern int parse_hide_refs_config(const char *var, const char *value, void *);
+extern int ref_is_hidden(const char *);
+
#endif /* REFS_H */
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index d16e5d3..d0702ed 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -126,4 +126,13 @@ test_expect_success 'Report match with --exit-code' '
test_cmp expect actual
'
+test_expect_success 'Hide some refs' '
+ test_config transfer.hiderefs refs/tags &&
+ git ls-remote . >actual &&
+ test_unconfig transfer.hiderefs &&
+ git ls-remote . |
+ sed -e "/ refs\/tags\//d" >expect &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 3dd220d..31ce954 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -12,6 +12,7 @@
#include "run-command.h"
#include "sigchain.h"
#include "version.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
@@ -28,10 +29,12 @@ static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<
static unsigned long oldest_have;
-static int multi_ack, nr_our_refs;
+static int multi_ack;
+static int nr_our_refs; /* This counts both advertised and unadvertised */
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -743,11 +746,14 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
unsigned char peeled[20];
mark_our_ref(refname, sha1, flag, cb_data);
+ if (ref_is_hidden(refname))
+ return 0;
if (capabilities)
- packet_write(1, "%s %s%c%s%s agent=%s\n",
+ packet_write(1, "%s %s%c%s%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
0, capabilities,
+ allow_tip_sha1_in_want ? " allow-tip-sha1-in-want" : "",
stateless_rpc ? " no-done" : "",
git_user_agent_sanitized());
else
@@ -758,11 +764,20 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int check_hidden_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ if (!ref_is_hidden(refname))
+ return 0;
+ allow_tip_sha1_in_want = 1;
+ return 1; /* terminate iteration over refs early */
+}
+
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
head_ref_namespaced(send_ref, NULL);
+ for_each_namespaced_ref(check_hidden_ref, NULL);
for_each_namespaced_ref(send_ref, NULL);
packet_flush(1);
} else {
@@ -779,6 +794,11 @@ static void upload_pack(void)
}
}
+static int upload_pack_config(const char *var, const char *value, void *unused)
+{
+ return parse_hide_refs_config(var, value, unused);
+}
+
int main(int argc, char **argv)
{
char *dir;
@@ -830,6 +850,7 @@ int main(int argc, char **argv)
die("'%s' does not appear to be a git repository", dir);
if (is_repository_shallow())
die("attempt to fetch/clone from a shallow repository");
+ git_config(upload_pack_config, NULL);
if (getenv("GIT_DEBUG_SEND_PACK"))
debug_fd = atoi(getenv("GIT_DEBUG_SEND_PACK"));
upload_pack();
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
* [PATCH v2 3/3] receive-pack: reject an attempt to update/delete a hidden ref
From: Junio C Hamano @ 2013-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
An attempt to update or delete a ref that is hidden from "git push"
is rejected. With this the server side can implement refs that are
only available for its own use, e.g. refs/pull/11/head used to hold
an incoming pull request at GitHub.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 3 ++-
builtin/receive-pack.c | 16 ++++++++++++++++
t/t5516-fetch-push.sh | 24 ++++++++++++++++++++++++
3 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 8e2853e..b7b407b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2063,7 +2063,8 @@ transfer.hiderefs::
more than one transfer.hiderefs configuration variables to
specify multiple prefix strings. A ref that has one of these
strings as its prefix is excluded, and is hidden from
- `git clone --mirror` and `git push :`.
+ `git clone --mirror` and `git push :`. An attempt to update
+ or delete a hidden ref by `git push` is rejected.
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5ed40be..a8248d9 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -696,6 +696,20 @@ static int iterate_receive_command_list(void *cb_data, unsigned char sha1[20])
return -1; /* end of list */
}
+static void reject_updates_to_hidden(struct command *commands)
+{
+ struct command *cmd;
+
+ for (cmd = commands; cmd; cmd = cmd->next) {
+ if (cmd->error_string || !ref_is_hidden(cmd->ref_name))
+ continue;
+ if (is_null_sha1(cmd->new_sha1))
+ cmd->error_string = "deny deleting a hidden ref";
+ else
+ cmd->error_string = "deny updating a hidden ref";
+ }
+}
+
static void execute_commands(struct command *commands, const char *unpacker_error)
{
struct command *cmd;
@@ -712,6 +726,8 @@ static void execute_commands(struct command *commands, const char *unpacker_erro
0, &cmd))
set_connectivity_errors(commands);
+ reject_updates_to_hidden(commands);
+
if (run_receive_hook(commands, pre_receive_hook, 0)) {
for (cmd = commands; cmd; cmd = cmd->next) {
if (!cmd->error_string)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6009372..8e8287a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1037,4 +1037,28 @@ test_expect_success 'push --prune refspec' '
! check_push_result $the_first_commit tmp/foo tmp/bar
'
+test_expect_success 'push to update a hidden ref' '
+ mk_test heads/master hidden/one hidden/two hidden/three &&
+ (
+ cd testrepo &&
+ git config transfer.hiderefs refs/hidden
+ ) &&
+
+ # push to unhidden ref succeeds normally
+ git push testrepo master:refs/heads/master &&
+ check_push_result $the_commit heads/master &&
+
+ # push to update a hidden ref should fail
+ test_must_fail git push testrepo master:refs/hidden/one &&
+ check_push_result $the_first_commit hidden/one &&
+
+ # push to delete a hidden ref should fail
+ test_must_fail git push testrepo master:refs/hidden/two &&
+ check_push_result $the_first_commit hidden/two &&
+
+ # idempotent push to update a hidden ref should fail
+ test_must_fail git push testrepo $the_first_commit:refs/hidden/three &&
+ check_push_result $the_first_commit hidden/three
+'
+
test_done
--
1.8.1.2.548.g0e4986f
^ permalink raw reply related
* Re: [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: David Aguilar @ 2013-01-29 1:37 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, git
In-Reply-To: <20130128192856.GA7498@serenity.lan>
On Mon, Jan 28, 2013 at 11:28 AM, John Keeping <john@keeping.me.uk> wrote:
> ---
> Junio, please can you squash this into f9924e5 on jk/mergetool,
> providing that David is OK with that?
This looks good to me.
> The original change breaks custom mergetool by making changing the logic
> around default functions so that they are now only defined when the tool
> file exists in $MERGE_TOOLS_DIR but we need the default implementations
> when a custom tool is in use, which by definition means that the file
> doesn't exist in $MERGE_TOOLS_DIR.
>
> git-mergetool--lib.sh | 18 +++++++++---------
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 1d0fb12..211ffe5 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -48,15 +48,6 @@ valid_tool () {
> setup_tool () {
> tool="$1"
>
> - if ! test -f "$MERGE_TOOLS_DIR/$tool"
> - then
> - # Use a special return code for this case since we want to
> - # source "defaults" even when an explicit tool path is
> - # configured since the user can use that to override the
> - # default path in the scriptlet.
> - return 2
> - fi
> -
> # Fallback definitions, to be overriden by tools.
> can_merge () {
> return 0
> @@ -80,6 +71,15 @@ setup_tool () {
> echo "$1"
> }
>
> + if ! test -f "$MERGE_TOOLS_DIR/$tool"
> + then
> + # Use a special return code for this case since we want to
> + # source "defaults" even when an explicit tool path is
> + # configured since the user can use that to override the
> + # default path in the scriptlet.
> + return 2
> + fi
> +
> # Load the redefined functions
> . "$MERGE_TOOLS_DIR/$tool"
>
> --
> 1.8.1.1
--
David
^ permalink raw reply
* Re: [PATCH] fixup! mergetools: simplify how we handle "vim" and "defaults"
From: Junio C Hamano @ 2013-01-29 3:02 UTC (permalink / raw)
To: David Aguilar; +Cc: John Keeping, git
In-Reply-To: <CAJDDKr5wsYqnBk+kvKj1qzUYKJBJ5nAiwMJZ=HpzPPgJf8BBTQ@mail.gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On Mon, Jan 28, 2013 at 11:28 AM, John Keeping <john@keeping.me.uk> wrote:
>> ---
>> Junio, please can you squash this into f9924e5 on jk/mergetool,
>> providing that David is OK with that?
>
> This looks good to me.
Thanks for a quick response. Will squash this in and rebuild the
two affected branches.
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Junio C Hamano @ 2013-01-29 3:03 UTC (permalink / raw)
To: Andrej E Baranov; +Cc: git, jrnieder, giuseppe.bilotta, jnareb
In-Reply-To: <1359416492-8597-1-git-send-email-admin@andrej-andb.ru>
Thanks; will queue.
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Bryan Turner @ 2013-01-29 3:28 UTC (permalink / raw)
To: git
In-Reply-To: <7vtxq0u1v3.fsf@alter.siamese.dyndns.org>
This won't work correctly as-is. The secure URL for Gravatar is
"https://secure.gravatar.com"[1], not "https://www.gravatar.com".
[1] See the "Secure Requests" section on:
https://en.gravatar.com/site/implement/images/
On 29 January 2013 14:03, Junio C Hamano <gitster@pobox.com> wrote:
>
> Thanks; will queue.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Jonathan Nieder @ 2013-01-29 4:12 UTC (permalink / raw)
To: Bryan Turner; +Cc: git, Andrej E Baranov, Junio C Hamano
In-Reply-To: <CAGyf7-GJkKDWdykq8iv90tU3TUR5ZKUf2bQc9sJokbq-RFYBYg@mail.gmail.com>
Hi Bryan,
Bryan Turner wrote:
> This won't work correctly as-is. The secure URL for Gravatar is
> "https://secure.gravatar.com"[1], not "https://www.gravatar.com".
Odd. "https://www.gravatar.com/" also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH] The images from picon and gravatar are always used over http://, and browsers give mixed contents warning when gitweb is served over https://.
From: Bryan Turner @ 2013-01-29 4:16 UTC (permalink / raw)
To: git
In-Reply-To: <20130129041206.GA15442@google.com>
Interesting. I wonder if they've changed it recently. I only pointed
it out because a software product I'm working on had a bug because it
was building the URLs with "https://www..." and the resulting images
were showing as X's instead of avatars. We had to change the
implementation to use "https://secure..." to get the avatars to load
correctly. That's been ~8 months ago now, though, so maybe it's no
longer the case. It seems like it would be much more convenient if
they just changed the scheme.
Bryan
On 29 January 2013 15:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi Bryan,
>
> Bryan Turner wrote:
>
>> This won't work correctly as-is. The secure URL for Gravatar is
>> "https://secure.gravatar.com"[1], not "https://www.gravatar.com".
>
> Odd. "https://www.gravatar.com/" also seems to work. I've put in a
> technical support query to find out what the Gravatar admins prefer.
>
> Thanks,
> Jonathan
^ permalink raw reply
* [RFC] The design of new pathspec features
From: Duy Nguyen @ 2013-01-29 4:35 UTC (permalink / raw)
To: git
For those who haven't followed closely, some coming changes allow us
to extend current pathspec syntax. We should soon be able to do
case-insenstive matching for example, or introduce "**" wildcard that
is currently used by gitignore. I just want to discuss about the new
syntax and behavior.
Many of these are already implemented in [1]. But I don't want you to
bother with buggy code yet. I'll resend it soon after 1.8.2.
--literal-pathspecs
===================
This feature is added by Jeff to disable globbing for all pathspecs. I
want to push it a bit further: disable all pathspec magic. This means
even ":/" is treated literally when --literal-pathspecs is set.
Because the intent behind this, as I understand, is for scripting, it
makes sense to keep it as literal as possible.
:(literal) magic
================
This magic is for people who want simple no-globbing pathspec (*). It
can be used in combination with other magic such as case-insensitive
matching. Incompatible with :(glob) magic below.
Global option --noglob-pathspecs is added to add :(literal) to
all. This is very similar to --literal-pathspecs. It just does not
disable pathspec magic. :(glob) magic overrides this global option.
(*) you can always disable wildcards by quoting them using backslash,
but that's inconvenient
:(glob) magic
=============
This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic pathspec does today. It uses
wildmatch(WM_PATHNAME), which basically means '*' does not match
slashes and "**" does.
Global option --glob-pathspecs is added to add :(glob) to all
pathspec. :(literal) magic overrides this global option.
fnmatch without FNM_PATHNAME is deprecated
==========================================
With the two magic above, people can switch between literal and new
globbing. There is no way to regain current matching behavior once
--[no]glob-pathspecs is used. And I think that's a good thing. New
globbing is more powerful than the current one. At some point, I'd
like to switch the matching behavior when neither literal nor magic
pathspec is specified. Either:
- make it literal by default
- make it new globbing by default
Which is more often used should be come the default. The question is
which.
Pathspec mnemonic
=================
Are :(literal) and :(glob) used often enough to deserve a short
mnemonic (like :/ is equivalent to :(top))? Which symbols should be
used? We can only use non-alphanumeric here, and '(', ')', ':' and '/'
are taken. It should be friendly to UNIX shell, no quoting is
preferred.
Another magic will come soon: case-insensitive matching. We may want
to reserve a mnemonic symbol for it as well.
We may also want to reserve option shortcuts for --noglob-pathspecs
and --glob-pathspecs. I suspect they'll be used more often.
New way to specify long pathspec magic
======================================
While testing the pathspec magic code, I grow tired of quoting :(glob)
every time because '(' is the start of a new shell. Which is one of
the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
specify long pathspec magic without quoting.
How about making ":q/xxx/" an equivalence of ":(xxx)"? Any character
(except ',') following 'q' is used as separator (similar to s/// from
sed). This violates the guidelines set in glossary-content.txt (only
use non-alphanumeric).
Another step futher is remove support for ":(xxx)" in favor of
":q(xxx)". We can do it today because I don't think anybody is using
":(top)" (the only supported magic) yet.
[1] https://github.com/pclouds/git/tree/parse-pathspec
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:05 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> Pathspec mnemonic
> =================
>
> Are :(literal) and :(glob) used often enough to deserve a short
> mnemonic (like :/ is equivalent to :(top))? Which symbols should be
> used?
I do not think we should discuss this before letting people gain
experience with various forms of magic; otherwise we would at best
end up with a concensus guess among uninformed.
> New way to specify long pathspec magic
> ======================================
>
> While testing the pathspec magic code, I grow tired of quoting :(glob)
> every time because '(' is the start of a new shell. Which is one of
> the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
> specify long pathspec magic without quoting.
Is this a real issue, though? Often interesting pathspecs do have
shell globs in them and we have to quote them anyway.
> How about making ":q/xxx/" an equivalence of ":(xxx)"?
A moderately strong no from here.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:07 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> For those who haven't followed closely, some coming changes allow us
> to extend current pathspec syntax. We should soon be able to do
> case-insenstive matching for example, or introduce "**" wildcard that
> is currently used by gitignore. I just want to discuss about the new
> syntax and behavior.
>
> Many of these are already implemented in [1]. But I don't want you to
> bother with buggy code yet. I'll resend it soon after 1.8.2.
I think I agree with everything up to the "fnmatch(~FNM_PATHNAME)"
part, from a quick read.
Thanks for writing this up.
^ permalink raw reply
* Re: [PATCH v2 0/3] transfer.hiderefs
From: Junio C Hamano @ 2013-01-29 5:13 UTC (permalink / raw)
To: git
In-Reply-To: <1359418412-26602-1-git-send-email-gitster@pobox.com>
Please take this as just a preview of early WIP. I think I may end
up doing moderate amount of refactoring as a preparatory step before
these patches, so nitpick-reviews are likely to become waste of
reviewer's time at this point.
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Duy Nguyen @ 2013-01-29 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpq0otw7y.fsf@alter.siamese.dyndns.org>
On Tue, Jan 29, 2013 at 12:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> New way to specify long pathspec magic
>> ======================================
>>
>> While testing the pathspec magic code, I grow tired of quoting :(glob)
>> every time because '(' is the start of a new shell. Which is one of
>> the reasons I introduce --[no]glob-pathspecs. Still I'd like a way to
>> specify long pathspec magic without quoting.
>
> Is this a real issue, though? Often interesting pathspecs do have
> shell globs in them and we have to quote them anyway.
:(icase) often won't (unless you combine with :(glob)). If we turn
grep's --max-depth feature into pathspec magic (feasible, just not
sure if it's actually useful), it won't need quoting either.
Even with :(glob), because of the complexity of the pathspec, it's
less likely to match anything and be expanded by bash, so no quoting
required.
>> How about making ":q/xxx/" an equivalence of ":(xxx)"?
>
> A moderately strong no from here.
--
Duy
^ permalink raw reply
* Re: [RFC] The design of new pathspec features
From: Junio C Hamano @ 2013-01-29 5:33 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <20130129043517.GA2878@duynguyen-vnpc.dek-tpc.internal>
Duy Nguyen <pclouds@gmail.com> writes:
> :(literal) magic
> ================
>
> This magic is for people who want simple no-globbing pathspec (*). It
> can be used in combination with other magic such as case-insensitive
> matching. Incompatible with :(glob) magic below.
>
> Global option --noglob-pathspecs is added to add :(literal) to
> all. This is very similar to --literal-pathspecs. It just does not
> disable pathspec magic. :(glob) magic overrides this global option.
>
> (*) you can always disable wildcards by quoting them using backslash,
> but that's inconvenient
Have you considered if it may be helpful to have a :(literal) magic
(or any magic in general) that applies only to the first N
characters of the pathspec pattern?
When you are in subdirectory and do a pathspec limited operation,
e.g.
cd Documentation && git ls-files "*.txt"
we internaly do an equivalent of this:
(1) first find out the "prefix", e.g. "Documentation/" in this
case;
(2) prepend the prefix to user-supplied pathspecs, e.g. yielding
"Documentation/*.txt" in this case; and
(3) use the resulting pathspecs to match against full pathnames
relative to the root of the working tree.
If the prefix had globbing character in it (e.g. we started in a
directory "D*cumentati*n" instead), we still should make sure that
that part matches literally, while allowing the globbing in
user-supplied part of the pathspec (e.g. "*.txt"). In the built in
code, you can work with the struct pathspec directly and mark the
entire prefix part with nowildcard_len field to match literally, but
if the above three-step logic needs to be implemented by a Porcelain
script like old days, they would need to quote glob specials in the
prefix part before appending user-supplied part to form the full
pathspec string.
I personally think we do not need to support something like this:
prefix=$(git rev-parse --show-prefix)
n=${#prefix}
pathspec=":(literal-$n)$prefix$1"
but other aspiring Porcelain script writers may disagree and would
want to have it. We can always solve it by giving them an easy and
uniform way to get the glob-quoted version of prefix to solve this
particular issue, i.e.
prefixq=$(git rev-parse --show-prefix-glob-quoted)
pathspec="$prefixq$1"
but magic that applies only to a substring may have other uses.
If you do not immediately think of any, let's not overengineer this.
Thanks.
^ permalink raw reply
* Cloning remote HTTP repository: Can only see 'master' branch
From: Michael Tyson @ 2013-01-29 5:54 UTC (permalink / raw)
To: git
Hello!
I've a readonly git repository that I'm hosting via HTTP (a bare git repository located within the appropriate directory on the server). I push to it via my own SSH account (local repository with a remote pointing to the ssh:// URL).
This has all worked fine so far - I push via ssh, and others can clone and pull via the HTTP URL.
I've recently added a branch - "beta" - which pushed just fine, but now cloning via the HTTP URL doesn't seem to show the new branch - just master:
$ git clone http://server.tld/path/to/repository.git repository
Cloning into 'repository'...
$ cd repository
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
Cloning via the readwrite ssh URL works fine though:
$ git clone ssh://user@server.tld:www/path/to/repository.git repository
Cloning into 'repository'...
stdin: is not a tty
remote: Counting objects: 225, done.
remote: Compressing objects: 100% (196/196), done.
remote: Total 225 (delta 109), reused 77 (delta 25)
Receiving objects: 100% (225/225), 9.55 MiB | 295 KiB/s, done.
Resolving deltas: 100% (109/109), done.
$ cd repository
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/beta
remotes/origin/master
I've tried 'git clone --mirror' just in case, but this just resulted in a bare repository with only the 'master' branch, still.
Anyone have any ideas about what I'm doing wrong?
Cheers,
Michael
^ 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