Re: What's cooking in git.git (Jul 2013, #03; Tue, 9)
On Jul 9, 2013, at 16:09, Junio C Hamano wrote: * km/svn-1.8-serf-only (2013-07-07) 2 commits - git-svn: allow git-svn fetching to work using serf - Git.pm: add new temp_is_locked function Comments? Since neither David nor Jonathan have piped in here (they were the two primarily involved in the discussion). On Jul 8, 2013, at 09:22, Junio C Hamano wrote: "Kyle J. McKay" writes: From: "Kyle J. McKay" Subject: Re: [PATCH v3 0/2] allow git-svn fetching to work using serf This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. [...] Thanks; I've queued this version to 'pu' at least tentatively. Is everybody who discussed the issue happy with the direction of this patch? I will add that David previously indicated this patch works for him: On Jul 6, 2013, at 00:17, David Rothenberger wrote: On 7/5/2013 8:41 PM, Kyle McKay wrote: This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. Thanks, Kyle. I confirm this is working for my problem cases as well. Subversion 1.8.0 was released less than a month ago on 2013-06-18 so there probably aren't too many git-svn users affected by this just yet. Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] prompt: do not double-discriminate detached HEAD
On Jul 7, 2013, at 10:53, Junio C Hamano wrote: John Szakmeister writes: On Sun, Jul 7, 2013 at 8:52 AM, Ramkumar Ramachandra > wrote: When GIT_PS1_SHOWCOLORHINTS is turned on, there is no need to put a detached HEAD within parenthesis: the color can be used to discriminate the detached HEAD. Signed-off-by: Ramkumar Ramachandra --- For cuteness :) Personally, I'd rather see the parens kept. Not everyone sees red very well--I know several people who can't see it at all, and it keeps it consistent with non-colored output. +1; I find red on many terminal emulators to be too dark to tell, especially in a small font, from black myself. +1; me too for the same reason. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-svn: allow git-svn fetching to work using serf
I forwarded the "SVNAllowBulkUpdates Off" question to the us...@subversion.apache.org list and here's the reply: On Jul 7, 2013, at 11:11, Lieven Govaerts wrote: On Sun, Jul 7, 2013 at 4:48 PM, Kyle McKay wrote: On Jul 7, 2013, at 06:39, Daniel Shahaf wrote: Kyle McKay wrote on Sat, Jul 06, 2013 at 19:46:40 -0700: On Jul 6, 2013, at 19:23, Jonathan Nieder wrote: Kyle McKay wrote: Unless bulk updates are disabled when using the serf access method (the only one available with svn 1.8) for https?: urls, apply_textdelta does indeed get called multiple times in a row without an intervening temp_release. You mean "Unless bulk updates are enabled" and "without an intervening close_file", right? The problem seems to be skelta mode although it may just be the fact that ra_serf has multiple connections outstanding and since ra_neon only ever has one it can't happen over ra_neon. If the server disables bulk updates (SVNAllowBulkUpdates Off) all clients are forced to use skelta mode, even ra_neon clients. As Brane and I have pointed out, git-svn can instruct libsvn_* to use bulk updates regardless of the server version, by setting SVN_CONFIG_OPTION_HTTP_BULK_UPDATES (new in 1.8). If you have questions about that, though, please address them to us...@subversion.apache.org (the proper list for API usage questions), not to me personally. According to the table at <http://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default >, if the server sets SVNAllowBulkUpdates Off, the client will be forced to use skelta no matter what the client setting is. Indeed, the server admin has the final say in which mode is actually used. SVNAllowBulkUpdates Off is only advised if the server admin wants a log line per accessed resource. I doubt it's used a lot, but the option is there. Is that table incorrect? No, that table is correct. Lieven So the final say so on whether or not bulk updates are allowed is on the server side which means git-svn really needs to handle skelta mode on the client side properly when using ra-serf to guarantee functionality with all subversion server configurations. Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-svn: allow git-svn fetching to work using serf
On Jul 6, 2013, at 19:23, Jonathan Nieder wrote:
Kyle McKay wrote:
Unless bulk updates are disabled when using the serf access method
(the only one available with svn 1.8) for https?: urls,
apply_textdelta does indeed get called multiple times in a row
without an intervening temp_release.
You mean "Unless bulk updates are enabled" and "without an intervening
close_file", right?
The problem seems to be skelta mode although it may just be the fact
that ra_serf has multiple connections outstanding and since ra_neon
only ever has one it can't happen over ra_neon.
If the server disables bulk updates (SVNAllowBulkUpdates Off) all
clients are forced to use skelta mode, even ra_neon clients.
This sounds like something that should be fixed in ra_serf.
Yes, but apparently it will not be.
But if the number of overlapping open text nodes is bounded by a low
number, the workaround of using multiple temp files sounds ok as a way
of dealing with unfixed versions of Subversion.
I believe it will never exceed twice ('svn_delta...' and
'git_blob...') the maximum number of serf connections allowed. Four
by default (hard-coded prior to svn 1.8). Limited to between 1 and 8
on svn 1.8. Actually it looks like from my testing that it won't ever
exceed twice the (max number of serf connections - 1).
Kyle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] allow git-svn fetching to work using serf
On Jul 6, 2013, at 18:37, Jonathan Nieder wrote: Kyle McKay wrote: On Jul 6, 2013, at 17:28, Jonathan Nieder wrote: David Rothenberger wrote: On 7/5/2013 8:41 PM, Kyle McKay wrote: Daniel Shahaf has suggested also setting "servers:global:http-bulk-updates=on". I have a patch that does this, but since turning on bulk updates has a possible performance penalty, I prefer your approach. I assume that's because http-bulk-updates defeats caching. If so, makes sense. Please forgive my ignorance: is there a bug filed about ra_serf's misbehavior here? Is it eventually going to be fixed and this is just a workaround, or is the growth in temp file use something we'd live with permanently? [...] Begin forwarded message: [...] [2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932 Ah, thanks for the context. It's still not clear to me how we know that ra_serf driving the editor in a non depth-first manner is the problem here. Has that explanation been confirmed somehow? For example, does the workaround mentioned by danielsh work? Does using ra_neon instead of ra_serf avoid trouble as well? Is there a simple explanation of why violating the depth-first constraint would lead to multiple blob (i.e., file, not directory) deltas being opened in a row without an intervening close? Using ra_neon seams to eliminate the problem. Using ra_neon has always been the default until svn 1.8 which drops ra_neon support entirely and always uses ra_serf for https?: urls. The workaround mentioned by danielsh won't work if the server has configured SVNAllowBulkUpdates Off because that will force use of skelta mode no matter what the client does. However, since ra_neon only ever has a single connection to the server it probably doesn't matter. Since ra_serf makes multiple connections to the server (hard-coded to 4 prior to svn 1.8, defaults to 4 in svn 1.8 but can be set to between 1 and 8) it makes sense there would be multiple active calls to apply_textdelta if processing is done as results are received on the multiple connections. Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-svn: allow git-svn fetching to work using serf
On Jul 6, 2013, at 17:24, Jonathan Nieder wrote:
(cc-ing Eric Wong, who wrote this code)
Hi,
Kyle McKay wrote:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
David Rothenberger has determined the cause to
be that ra_serf does not drive the delta editor in a depth-first
manner [...]. Instead, the calls come in this order:
[...]
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -315,11 +315,13 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
return undef if $self->is_path_ignored($fb->{path});
- my $fh = $::_repository->temp_acquire('svn_delta');
+ my $suffix = 0;
+ ++$suffix while $::_repository->temp_is_locked("svn_delta_${$}_
$suffix");
+ my $fh = $::_repository->temp_acquire("svn_delta_${$}_$suffix");
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
- my $base = $::_repository->temp_acquire('git_blob');
+ my $base = $::_repository->temp_acquire("git_blob_${$}_$suffix");
Thanks for your work tracking this down.
I'm a bit confused. Are you saying that apply_textdelta gets called
multiple times in a row without an intervening close_file?
Unless bulk updates are disabled when using the serf access method
(the only one available with svn 1.8) for https?: urls,
apply_textdelta does indeed get called multiple times in a row without
an intervening temp_release.
Two temp files are created for each apply_textdelta ('svn_delta...'
and 'git_blob...'). In my tests it seems that most of the time the
two temp files are enough, but occasionally as many as six will be
open at the same time.
I suspect this maximum number is related to the maximum number of
simultaneous connections the serf access method will use which
defaults to 4. Therefore I would expect to see as many as 8 temp
files (4 each for 'svn_delta...' and 'git_blob...'), but I have only
been able to trigger creation of 6 temp files so far.
Kyle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] allow git-svn fetching to work using serf
On Jul 6, 2013, at 17:28, Jonathan Nieder wrote: David Rothenberger wrote: On 7/5/2013 8:41 PM, Kyle McKay wrote: Daniel Shahaf has suggested also setting "servers:global:http-bulk-updates=on". I have a patch that does this, but since turning on bulk updates has a possible performance penalty, I prefer your approach. I assume that's because http-bulk-updates defeats caching. If so, makes sense. Please forgive my ignorance: is there a bug filed about ra_serf's misbehavior here? Is it eventually going to be fixed and this is just a workaround, or is the growth in temp file use something we'd live with permanently? Apparently it will not be fixed: Begin forwarded message: From: David Rothenberger Date: July 5, 2013 16:14:12 PDT To: git@vger.kernel.org Subject: Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode I traced git-svn and discovered that the error is due to a known problem in the SVN APIs. ra_serf does not drive the delta editor in a depth-first manner as required by the API [1]. Instead, the calls come in this order: 1. open_root 2. open_directory 3. add_file 4. apply_textdelta 5. add_file 6. apply_textdelta This is a known issue [2] and one that the Subversion folks have elected not to fix [3]. [1] http://subversion.apache.org/docs/api/latest/structsvn__delta__editor__t.html#details [2] http://subversion.tigris.org/issues/show_bug.cgi?id=2932 [3] http://subversion.tigris.org/issues/show_bug.cgi?id=3831 The summary of [3] which is marked RESOLVED,FIXED is "Add errata / release note noise around ra_serf's editor drive violations". Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] git-svn: allow git-svn fetching to work using serf
When attempting to git-svn fetch files from an svn https?: url using
the serf library (the only choice starting with svn 1.8) the following
errors can occur:
Temp file with moniker 'svn_delta' already in use at Git.pm line 1250
Temp file with moniker 'git_blob' already in use at Git.pm line 1250
David Rothenberger has determined the cause to
be that ra_serf does not drive the delta editor in a depth-first
manner [...]. Instead, the calls come in this order:
1. open_root
2. open_directory
3. add_file
4. apply_textdelta
5. add_file
6. apply_textdelta
This change causes a new temp file moniker to be generated if the
one that would otherwise have been used is currently locked.
Signed-off-by: Kyle J. McKay
---
perl/Git/SVN/Fetcher.pm | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index bd17418..10edb27 100644
--- a/perl/Git/SVN/Fetcher.pm
+++ b/perl/Git/SVN/Fetcher.pm
@@ -315,11 +315,13 @@ sub change_file_prop {
sub apply_textdelta {
my ($self, $fb, $exp) = @_;
return undef if $self->is_path_ignored($fb->{path});
- my $fh = $::_repository->temp_acquire('svn_delta');
+ my $suffix = 0;
+ ++$suffix while $::_repository->temp_is_locked("svn_delta_${$}_
$suffix");
+ my $fh = $::_repository->temp_acquire("svn_delta_${$}_$suffix");
# $fh gets auto-closed() by SVN::TxDelta::apply(),
# (but $base does not,) so dup() it for reading in close_file
open my $dup, '<&', $fh or croak $!;
- my $base = $::_repository->temp_acquire('git_blob');
+ my $base = $::_repository->temp_acquire("git_blob_${$}_$suffix");
if ($fb->{blob}) {
my ($base_is_link, $size);
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode
On Jul 5, 2013, at 16:14, David Rothenberger wrote: On 7/5/2013 1:48 PM, David Rothenberger wrote: I recently upgraded my Subversion server to 1.8.0 and started receiving the following error from "git svn fetch": Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/ vendor_perl/5.10/Git.pm line 1024. This occurs only when using an http:// URL; svn:// URLs work fine. I have created a patch (separate emails) that seems to work. However, if the server being fetched against is not configured well for use with serf then "Error retrieving REPORT (54): Connection reset by peer Git/SVN/Ra.pm line 282" errors can occur and/or the fetch can be horribly slow compared to using neon. If the "Connection reset" error occurs, the fetch can be restarted to get more revisions until it dies again. Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] allow git-svn fetching to work using serf
This patch allows git-svn to fetch successfully using the serf library when given an https?: url to fetch from. Unfortunately some svn servers do not seem to be configured well for use with the serf library. This can cause fetching to take longer compared to the neon library or actually cause timeouts during the fetch. When timeouts occur git-svn can be safely restarted to fetch more revisions. A new temp_is_locked function has been added to Git.pm to facilitate using the minimal number of temp files possible when using serf. The problem that occurs when running git-svn fetch using the serf library is that the previously used temp file is not always unlocked before the next temp file needs to be used. To work around this problem, a new temp name is used if the temp name that would otherwise be chosen is currently locked. This patch may not be all that is required, but at least it is a starting point. Daniel Shahaf has suggested also setting "servers:global:http-bulk- updates=on". Kyle J. McKay (2): Git.pm: add new temp_is_locked function git-svn: allow git-svn fetching to work using serf perl/Git.pm | 17 - perl/Git/SVN/Fetcher.pm | 6 -- 2 files changed, 20 insertions(+), 3 deletions(-) -- 1.8.3 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Git.pm: add new temp_is_locked function
The temp_is_locked function can be used to determine whether
or not a given name previously passed to temp_acquire is
currently locked.
Signed-off-by: Kyle J. McKay
---
perl/Git.pm | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/perl/Git.pm b/perl/Git.pm
index 7a252ef..5416b5a 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -61,7 +61,7 @@ require Exporter;
remote_refs prompt
get_tz_offset
credential credential_read credential_write
-temp_acquire temp_release temp_reset temp_path);
+temp_acquire temp_is_locked temp_release temp_reset
temp_path);
=head1 DESCRIPTION
@@ -1206,6 +1206,21 @@ sub temp_acquire {
$temp_fd;
}
+=item temp_is_locked ( NAME )
+
+Returns true if the file mapped to C is currently locked.
+
+If true is returned, an attempt to C the same C
will
+throw an error.
+
+=cut
+
+sub temp_is_locked {
+ my ($self, $name) = _maybe_self(@_);
+ my $temp_fd = \$TEMP_FILEMAP{$name};
+ defined $$temp_fd && $$temp_fd->opened && $TEMP_FILES{$$temp_fd}
{locked};
+}
+
=item temp_release ( NAME )
=item temp_release ( FILEHANDLE )
--
1.8.3
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode
On Jul 5, 2013, at 16:07, David Rothenberger wrote: On 7/5/2013 3:58 PM, Kyle McKay wrote: On Jul 5, 2013, at 13:48, David Rothenberger wrote: I recently upgraded my Subversion server to 1.8.0 and started receiving the following error from "git svn fetch": Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/vendor_perl/5.10/Git.pm line 1024. This occurs only when using an http:// URL; svn:// URLs work fine. [snip] The client is Cygwin: svn version 1.8.0 and git version 1.8.3.2. The subversion 1.8 release has removed the neon library, all svn client http access now always goes through the serf library. If you put "http-library = serf" in the "[global]" section of the "~/.subversion/servers" file you will get the 'svn_delta' error with git-svn when running earlier versions of the svn client as well. That was not my experience. I did try this with the 1.7 perl bindings and libraries and with "http-library = serf" in by servers and it worked fine. I confirmed that serf was being used with a Wireshark trace. I had it always fail right away from my home ISP (kinda slow connection), but when running on a host with quite a different internet connection it would sometimes run for a while before generating the error (maybe a couple hundred revisions fetched) for some sources, but it would *always* eventually fail. For this reason I also believe the problem is timing sensitive. Try doing "git svn clone --quiet http://dev.heuristiclab.com/svn/hl/ core" with "~/.subversion/servers" section "[global]" including "http_library = serf". I find this one always seems to fail right away for me with git-svn over serf but will clone fine over neon (if you can stand to wait long enough). I have been looking into using serf for git-svn clones ever since I discovered how very much faster snvrdump works on an http url over serf as compared to neon. Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-svn "Temp file with moniker 'svn_delta' already in use" and skelta mode
On Jul 5, 2013, at 13:48, David Rothenberger wrote: I recently upgraded my Subversion server to 1.8.0 and started receiving the following error from "git svn fetch": Temp file with moniker 'svn_delta' already in use at /usr/lib/perl5/ vendor_perl/5.10/Git.pm line 1024. This occurs only when using an http:// URL; svn:// URLs work fine. [snip] The client is Cygwin: svn version 1.8.0 and git version 1.8.3.2. The subversion 1.8 release has removed the neon library, all svn client http access now always goes through the serf library. If you put "http-library = serf" in the "[global]" section of the "~/.subversion/servers" file you will get the 'svn_delta' error with git-svn when running earlier versions of the svn client as well. I initially reported this to the subversion users mailing list, but was (not so politely) told to report this to the git-svn authors. I'm not so sure, since the problem goes away simply by downgrading the subversion-perl bindings back to 1.7. That changes the default http client access back to neon which doesn't exhibit the problem. Adding "http-library = serf" as described above will make the problem reappear with the 1.7 subversion-perl bindings (and the 1.6 as well). Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] config: add support for http..* settings
The value is considered a match to a url if the
value is a prefix of the url which ends on a path component
boundary ('/'). So "https://example.com/test"; will match
"https://example.com/test"; and "https://example.com/test/too";
but not "https://example.com/testextra";.
Longer matches take precedence over shorter matches with
environment variable settings taking precedence over all.
With this configuration:
[http]
useragent = other-agent
noEPSV = true
[http "https://example.com";]
useragent = example-agent
sslVerify = false
[http "https://example.com/path";]
useragent = path-agent
The "https://other.example.com/"; url will have useragent
"other-agent" and sslVerify will be on.
The "https://example.com/"; url will have useragent
"example-agent" and sslVerify will be off.
The "https://example.com/path/sub"; url will have useragent
"path-agent" and sslVerify will be off.
All three of examples will have noEPSV enabled.
Signed-off-by: Kyle J. McKay
---
The credentials configuration values already support url-specific
configuration items in the form credential..*. This patch
adds similar support for http configuration values.
Documentation/config.txt | 8 +++
http.c | 125 +++
+---
2 files changed, 116 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b4d4887..27d19a1 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1531,6 +1531,14 @@ http.useragent::
of common USER_AGENT strings (but not including those like git/1.7.1).
Can be overridden by the 'GIT_HTTP_USER_AGENT' environment variable.
+http..*::
+ Any of the http.* options above can be applied selectively to some
urls.
+ For example "http.https://example.com.useragent"; would set the user
+ agent only for https connections to example.com. The value
+ matches a url if it is a prefix of the url matching at a '/' boundary.
+ Longer matches take precedence over shorter ones with the
+ environment variable settings taking precedence over all.
+
i18n.commitEncoding::
Character encoding the commit messages are stored in; Git itself
does not care per se, but this information is necessary e.g. when
diff --git a/http.c b/http.c
index 2d086ae..7ddf9af 100644
--- a/http.c
+++ b/http.c
@@ -30,6 +30,34 @@ static CURL *curl_default;
char curl_errorstr[CURL_ERROR_SIZE];
+enum http_option_type {
+ o_post_buffer = 0,
+ o_min_sessions,
+#ifdef USE_CURL_MULTI
+ o_max_requests,
+#endif
+ o_ssl_verify,
+ o_ssl_try,
+ o_ssl_cert,
+#if LIBCURL_VERSION_NUM >= 0x070903
+ o_ssl_key,
+#endif
+#if LIBCURL_VERSION_NUM >= 0x070908
+ o_ssl_capath,
+#endif
+ o_ssl_cainfo,
+ o_low_speed,
+ o_low_time,
+ o_no_epsv,
+ o_http_proxy,
+ o_cookie_file,
+ o_user_agent,
+ o_passwd_req,
+ o_max
+};
+
+static int http_option_maxlen[o_max];
+
static int curl_ssl_verify = -1;
static int curl_ssl_try;
static const char *ssl_cert;
@@ -65,6 +93,23 @@ static struct curl_slist *no_pragma_header;
static struct active_request_slot *active_queue_head;
+static int http_options_url_match(const char *url, const char
*config_url)
+{
+ /*
+* config option with config_url matches url if config_url is a
+* prefix of url and the match ends on a path component boundary.
+* the return value is the length of the match in characters or
+* 0 for no match.
+*/
+ size_t url_len, config_url_len = strlen(config_url);
+ if (!config_url || strncmp(url, config_url, config_url_len))
+ return 0;
+ url_len = strlen(url);
+ if (url_len == config_url_len || url[config_url_len - 1] == '/' ||
url[config_url_len] == '/')
+ return url[config_url_len - 1] == '/' ? config_url_len - 1 :
config_url_len;
+ return 0;
+}
+
size_t fread_buffer(char *ptr, size_t eltsize, size_t nmemb, void
*buffer_)
{
size_t size = eltsize * nmemb;
@@ -143,32 +188,65 @@ static void process_curl_messages(void)
static int http_options(const char *var, const char *value, void *cb)
{
- if (!strcmp("http.sslverify", var)) {
+#define CHECKLEN(opt) if (http_option_maxlen[opt] > matchlen) return
0; \
+ else http_option_maxlen[opt] = matchlen
+
+ const char *url = (const char *)cb;
+ const char *key, *dot;
+ int matchlen = 0;
+
+ key = skip_prefix(var, "http.");
+ if (!key)
+ return git_default_config(var, value, cb);
+
+ dot = strrchr(key, '.');
+ if (dot) {
+ char *config_url = xmemdupz(key, dot - key);
+ matchlen = http_options_url_match(url, config_url);
+ free(config_url);
+ if (!matchlen)
+ return git_default_config(var, value, cb);
+
Re: repo.or.cz being not well???
On Jul 2, 2013, at 09:55, Andreas Schwab wrote: Kyle McKay writes: Do you feel that it's important to accept these alternate URL versions that are not listed on the project page: 1) Optional trailing '/' 2) For the ssh scp form, optional leading '/' 3) Optional trailing .git Thank you for your patience. The 3 URL variants listed above should all be working again now. On Jul 1, 2013, at 16:10, Junio C Hamano wrote: I just (1) was curious, as getting "error 403" when I didn't mean to talk to an HTTP server was strange, The '403' prefix has also been removed from ssh protocol error messages to reduce confusion. Regards, Kyle -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: repo.or.cz being not well???
My apologies. repo.or.cz recently had some updates to support: 1) smart HTTP fetch 2) smart HTTP push (over https) 3) user removal of projects Along with those updates it started doing more validation on paths. I believe all the paths listed on http://repo.or.cz/w/alt-git.git are accepted as shown. I was not previously aware that URLs not shown on that page were accepted, thank you for bringing it to my attention. Do you feel that it's important to accept these alternate URL versions that are not listed on the project page: 1) Optional trailing '/' 2) For the ssh scp form, optional leading '/' Regards, Kyle On Jul 1, 2013, at 15:21, Junio C Hamano wrote: Junio C Hamano writes: Has something changed recently at repo.or.cz, accepting pushes over ssh, in the past few days? I am getting this: $ git push -n -v repo.or.cz:srv/git/alt-git.git/ 403 forbidden fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Nevermind, I figured it out. $ git push repo.or.cz:/srv/git/alt-git.git seems to be the new way to spell the scp style push. Two points to note, just in case it would help other users, are (1) The repository hierarchy is no longer under your initial directory and you have to explicitly ask for /srv/$path; and (2) You used to be able to, but no longer are allowed, to have a trailing slash in your repository URL. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
