* Re: [PATCH] Build on Debian GNU/Hurd
From: Gerrit Pape @ 2006-09-19 17:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vr6yce5ky.fsf@assigned-by-dhcp.cox.net>
On Fri, Sep 15, 2006 at 10:35:57PM -0700, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > Patch from Cyril Brulebois to make the build process detect and support the
> > Debian GNU/Hurd architecture, see
> > http://bugs.debian.org/379841
> >
> > Signed-off-by: Gerrit Pape <pape@smarden.org>
> >
> > +ifeq ($(uname_S),GNU)
> > + # GNU stands for GNU/Hurd
> > + NO_STRLCPY = YesPlease
> > + ALL_CFLAGS += -DPATH_MAX=4096
> > +endif
>
> Two questions come to mind. (1) Does GNU stand for GNU/Hurd and
> nobody else? (2) Does everybody else have PATH_MAX?
I'm not that familiar with the Hurd, but (1) seems to be so according
to http://www.gnu.org/software/hurd/hurd.html; it looks like either GNU
or GNU/Hurd is used. (2) For IRIX64 PATH_MAX also is defined explicitly
git$ grep -B7 -A3 PATH_MAX Makefile
ifeq ($(uname_S),IRIX64)
NO_IPV6=YesPlease
NO_SETENV=YesPlease
NO_STRCASESTR=YesPlease
NO_STRLCPY = YesPlease
NO_SOCKADDR_STORAGE=YesPlease
SHELL_PATH=/usr/gnu/bin/bash
ALL_CFLAGS += -DPATH_MAX=1024
# for now, build 32-bit version
ALL_LDFLAGS += -L/usr/lib32
endif
that's where I got it from.
> Adding NO_STRLCPY I do not have much problems with, but
> something like the attached may be cleaner to deal with PATH_MAX;
> of course now there is an issue of what the appropriate value
> for that symbol should be.
It's been so before it seems, I'm not sure why it changed.
http://www.debian.org/ports/hurd/hurd-devel-debian says one cannot
expect PATH_MAX to be defined on a POSIX system, so defining it
conditionally IMHO is the right thing.
git$ PAGER=cat git log -p 579d1fb..8e76483
commit 8e76483ce0ce256b01345abc4ca97b1f94aed354
Author: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Date: Sun Jul 30 17:00:40 2006 +0100
Fix header breakage due to redefining PATH_MAX.
The header builtin.h was, incorrectly, redefining PATH_MAX which
causes a header order dependency in builtin-write-tree.c. The fix
is to simply include <limits.h> directly to obtain the correct
definition of PATH_MAX.
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff --git a/builtin.h b/builtin.h
index 1c8637a..88c4d84 100644
--- a/builtin.h
+++ b/builtin.h
@@ -2,10 +2,7 @@ #ifndef BUILTIN_H
#define BUILTIN_H
#include <stdio.h>
-
-#ifndef PATH_MAX
-# define PATH_MAX 4096
-#endif
+#include <limits.h>
extern const char git_version_string[];
HTH, Gerrit.
^ permalink raw reply
* Re: [PATCH] gitweb: Require project for all actions except few
From: Matthias Lederhofer @ 2006-09-19 13:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609191438.28685.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> +if ($action !~ m/^opml|project_list|project_index$/ &&
The regexp should be:
m/^(opml|project_list|project_index)$/ &&
% (echo opml_foo; echo foo_project_list_bar; echo bar_project_index) |
perl -ne 'print if m/^opml|project_list|project_index$/;'
opml_foo
foo_project_list_bar
bar_project_index
^ permalink raw reply
* [PATCH] gitweb: Require project for all actions except few
From: Jakub Narebski @ 2006-09-19 12:38 UTC (permalink / raw)
To: git
Require that project (repository) is given for all actions except project_list,
project_index and opml.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 034cdf1..34311ee 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -341,6 +341,10 @@ if (defined $project) {
if (!defined($actions{$action})) {
die_error(undef, "Unknown action");
}
+if ($action !~ m/^opml|project_list|project_index$/ &&
+ !$project) {
+ die_error(undef, "Project needed");
+}
$actions{$action}->();
exit;
--
1.4.2.1
^ permalink raw reply related
* [PATCH 2/2] gitweb: Make git_get_refs_list do work of git_get_references
From: Jakub Narebski @ 2006-09-19 12:33 UTC (permalink / raw)
To: git
In-Reply-To: <200609191430.51252.jnareb@gmail.com>
Make git_get_refs_list do also work of git_get_references, to avoid
calling git-peek-remote twice. Change meaning of git_get_refs_list
meaning: it is now type, and not a full path, e.g. we now use
git_get_refs_list("heads") instead of former
git_get_refs_list("refs/heads").
Modify git_summary to use only one call to git_get_refs_list instead
of one call to git_get_references and two to git_get_refs_list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Benchmarks show that this version is slightly faster than
"before" version:
2626.133 +/- 98.1 ms after vs 3086.579 +/- 85.0 ms before (summary)
2233.814 +/- 13.9 ms after vs 2504.025 +/- 46.1 ms before (tags)
869.533 +/- 7.7 ms after vs 979.281 +/- 88.1 ms before (heads)
gitweb/gitweb.perl | 66 +++++++++++++++++++++++++++++++++-------------------
1 files changed, 42 insertions(+), 24 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 034a88c..01fae94 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1119,7 +1119,8 @@ ## .....................................
## parse to array of hashes functions
sub git_get_refs_list {
- my $ref_dir = shift;
+ my $type = shift || "";
+ my %refs;
my @reflist;
my @refs;
@@ -1127,14 +1128,21 @@ sub git_get_refs_list {
or return;
while (my $line = <$fd>) {
chomp $line;
- if ($line =~ m/^([0-9a-fA-F]{40})\t$ref_dir\/?([^\^]+)$/) {
- push @refs, { hash => $1, name => $2 };
- } elsif ($line =~ m/^[0-9a-fA-F]{40}\t$ref_dir\/?(.*)\^\{\}$/ &&
- $1 eq $refs[-1]{'name'}) {
- # most likely a tag is followed by its peeled
- # (deref) one, and when that happens we know the
- # previous one was of type 'tag'.
- $refs[-1]{'type'} = "tag";
+ if ($line =~ m/^([0-9a-fA-F]{40})\trefs\/($type\/?([^\^]+))(\^\{\})?$/) {
+ if (defined $refs{$1}) {
+ push @{$refs{$1}}, $2;
+ } else {
+ $refs{$1} = [ $2 ];
+ }
+
+ if (! $4) { # unpeeled, direct reference
+ push @refs, { hash => $1, name => $3 }; # without type
+ } elsif ($3 eq $refs[-1]{'name'}) {
+ # most likely a tag is followed by its peeled
+ # (deref) one, and when that happens we know the
+ # previous one was of type 'tag'.
+ $refs[-1]{'type'} = "tag";
+ }
}
}
close $fd;
@@ -1150,7 +1158,7 @@ sub git_get_refs_list {
}
# sort refs by age
@reflist = sort {$b->{'epoch'} <=> $a->{'epoch'}} @reflist;
- return \@reflist;
+ return (\@reflist, \%refs);
}
## ----------------------------------------------------------------------
@@ -2114,14 +2122,14 @@ sub git_tags_body {
sub git_heads_body {
# uses global variable $project
- my ($taglist, $head, $from, $to, $extra) = @_;
+ my ($headlist, $head, $from, $to, $extra) = @_;
$from = 0 unless defined $from;
- $to = $#{$taglist} if (!defined $to || $#{$taglist} < $to);
+ $to = $#{$headlist} if (!defined $to || $#{$headlist} < $to);
print "<table class=\"heads\" cellspacing=\"0\">\n";
my $alternate = 0;
for (my $i = $from; $i <= $to; $i++) {
- my $entry = $taglist->[$i];
+ my $entry = $headlist->[$i];
my %tag = %$entry;
my $curr = $tag{'id'} eq $head;
if ($alternate) {
@@ -2291,7 +2299,19 @@ sub git_summary {
my $owner = git_get_project_owner($project);
- my $refs = git_get_references();
+ my ($reflist, $refs) = git_get_refs_list();
+
+ my @taglist;
+ my @headlist;
+ foreach my $ref (@$reflist) {
+ if ($ref->{'name'} =~ s!^heads/!!) {
+ push @headlist, $ref;
+ } else {
+ $ref->{'name'} =~ s!^tags/!!;
+ push @taglist, $ref;
+ }
+ }
+
git_header_html();
git_print_page_nav('summary','', $head);
@@ -2321,17 +2341,15 @@ sub git_summary {
git_shortlog_body(\@revlist, 0, 15, $refs,
$cgi->a({-href => href(action=>"shortlog")}, "..."));
- my $taglist = git_get_refs_list("refs/tags");
- if (defined @$taglist) {
+ if (@taglist) {
git_print_header_div('tags');
- git_tags_body($taglist, 0, 15,
+ git_tags_body(\@taglist, 0, 15,
$cgi->a({-href => href(action=>"tags")}, "..."));
}
- my $headlist = git_get_refs_list("refs/heads");
- if (defined @$headlist) {
+ if (@headlist) {
git_print_header_div('heads');
- git_heads_body($headlist, $head, 0, 15,
+ git_heads_body(\@headlist, $head, 0, 15,
$cgi->a({-href => href(action=>"heads")}, "..."));
}
@@ -2542,7 +2560,7 @@ sub git_tags {
git_print_page_nav('','', $head,undef,$head);
git_print_header_div('summary', $project);
- my $taglist = git_get_refs_list("refs/tags");
+ my ($taglist) = git_get_refs_list("tags");
if (defined @$taglist) {
git_tags_body($taglist);
}
@@ -2555,9 +2573,9 @@ sub git_heads {
git_print_page_nav('','', $head,undef,$head);
git_print_header_div('summary', $project);
- my $taglist = git_get_refs_list("refs/heads");
- if (defined @$taglist) {
- git_heads_body($taglist, $head);
+ my ($headlist) = git_get_refs_list("heads");
+ if (defined @$headlist) {
+ git_heads_body($headlist, $head);
}
git_footer_html();
}
--
1.4.2.1
^ permalink raw reply related
* [PATCH 0/2] Make git_get_refs_list do work of git_get_references
From: Jakub Narebski @ 2006-09-19 12:30 UTC (permalink / raw)
To: git
This is resend of short series of patches. Second patch in series
was corrected twice ([PATCH 2/2 (take 2)] and [PATCH 2/2 (take 3)]),
but neither of corrections made to git mailing list.
Shortlog:
[PATCH 1/2] gitweb: Always use git-peek-remote in git_get_references
[PATCH 2/2] gitweb: Make git_get_refs_list do work of git_get_references
Diffstat:
gitweb/gitweb.perl | 76 ++++++++++++++++++++++++++++++----------------------
1 files changed, 44 insertions(+), 32 deletions(-)
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH 1/2] gitweb: Always use git-peek-remote in git_get_references
From: Jakub Narebski @ 2006-09-19 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <200609191430.51252.jnareb@gmail.com>
Instead of trying to read info/refs file, which might not be present
(we did fallback to git-ls-remote), always use git-peek-remote in
git_get_references.
It is preparation for git_get_refs_info to also return references
info. We cannot use info/refs for git_get_refs_info as the information
contained therein is usually stale.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c77270c..034a88c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -828,16 +828,10 @@ sub git_get_project_owner {
sub git_get_references {
my $type = shift || "";
my %refs;
- my $fd;
# 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
# c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
- if (-f "$projectroot/$project/info/refs") {
- open $fd, "$projectroot/$project/info/refs"
- or return;
- } else {
- open $fd, "-|", git_cmd(), "ls-remote", "."
- or return;
- }
+ open my $fd, "-|", $GIT, "peek-remote", "$projectroot/$project/"
+ or return;
while (my $line = <$fd>) {
chomp $line;
--
1.4.2.1
^ permalink raw reply related
* Re: Patch for http-fetch.c and older curl releases
From: Art Haas @ 2006-09-19 12:20 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0609191027020.19042@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Sep 19, 2006 at 10:31:12AM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 18 Sep 2006, Art Haas wrote:
>
> > +#if LIBCURL_VERSION_NUM < 0x070f05
> > +#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> > +#endif
>
> If you go to
>
> http://cool.haxx.se/cvs.cgi/curl/include/curl/curl.h?annotate=1.308
>
> and search for HTTP_RETURNED_ERROR, it shows that revision "badger_1.180"
> introduced it, which you can verify by clicking on the link to the diff.
> This diff also says that the LIBCURL_VERSION_NUM (which is changed just
> after a release in the curl project) is 0x70a03. Thus, you should check
> for 0x70a03 instead of 0x70f05.
Hi.
Here's a patch that checks for that version of libcurl.
Signed-off-by: Art Haas <ahaas@airmail.net>
diff --git a/http.h b/http.h
index 9ca16ac..6e12e41 100644
--- a/http.h
+++ b/http.h
@@ -22,6 +22,10 @@ #if LIBCURL_VERSION_NUM < 0x070c04
#define NO_CURL_EASY_DUPHANDLE
#endif
+#if LIBCURL_VERSION_NUM < 0x070a03
+#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
+#endif
+
struct slot_results
{
CURLcode curl_result;
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply related
* [PATCH] gitweb: Fix mimetype_guess_file for files with multiple extensions
From: Jakub Narebski @ 2006-09-19 11:57 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060919082925.GC31940@admingilde.org>
Fix getting correct mimetype for "blob_plain" view for files which have
multiple extensions, e.g. foo.1.html; now only the last extension
is used to find mimetype.
Noticed by Martin Waitz.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is much simpler (and faster!) correction to the mentioned problem.
I just don't grok regular expressions, not completly.
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 01fae94..034cdf1 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1199,7 +1199,7 @@ sub mimetype_guess_file {
}
close(MIME);
- $filename =~ /\.(.*?)$/;
+ $filename =~ /\.([^.]*)$/;
return $mimemap{$1};
}
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH] gitweb: more support for PATH_INFO based URLs
From: Jakub Narebski @ 2006-09-19 9:49 UTC (permalink / raw)
To: git
In-Reply-To: <20060919081933.GB31940@admingilde.org>
Martin Waitz wrote:
> On Sun, Sep 17, 2006 at 04:20:23PM +0200, Jakub Narebski wrote:
>> matled (Matthias Lederhofer) on #git proposed to use ':' as a separator
>> between branch and filename (as branch doesn't need to be flat,
>> e.g. "jc/diff" like branch name), because valid branch name cannot contain
>> ':' (and this limit is only for branch name).
>
> you are right, my patch doesn't work with hierarchical branch names.
> However using ":" alone does not work eighter.
> My main motivation for this patch was to be able to export .html files
> and to have working links between them.
> However a <a href="main.html"> link inside "branch:index.html" would
> try to get "main.html" and not "branch:main.html".
>
> Perhaps use ":/" as separator?
That would be _very_ easy to add. Just strip leading "/" from pathname,
and we can have
path/to/project.git/hierarchical/branch:/path/to/filename
By the way, besides hierarchical branches, we might need this if
the repository (project) has the branch (head) and tag with the same name,
and we want to select one or the other.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: use correct mime type even if filename has multiple dots.
From: Martin Waitz @ 2006-09-19 9:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vejua7um3.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 515 bytes --]
hoi :)
On Sun, Sep 17, 2006 at 01:41:40AM -0700, Junio C Hamano wrote:
> - read in mime.types, sort the entries with length of the
> suffixes (longer first);
>
> - try matching the suffixes from longer to shorter and pick the
> first match.
>
> Without that, you would not be able to cope with a /etc/mime.types
> that looks like this, no?
>
> application/a a
> application/b b.a
>
> Perhaps something like the attached.
works perfectly, thanks.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Patch for http-fetch.c and older curl releases
From: Johannes Schindelin @ 2006-09-19 8:31 UTC (permalink / raw)
To: Art Haas; +Cc: Junio C Hamano, git
In-Reply-To: <20060918235753.GG1261@artsapartment.org>
Hi,
On Mon, 18 Sep 2006, Art Haas wrote:
> +#if LIBCURL_VERSION_NUM < 0x070f05
> +#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> +#endif
If you go to
http://cool.haxx.se/cvs.cgi/curl/include/curl/curl.h?annotate=1.308
and search for HTTP_RETURNED_ERROR, it shows that revision "badger_1.180"
introduced it, which you can verify by clicking on the link to the diff.
This diff also says that the LIBCURL_VERSION_NUM (which is changed just
after a release in the curl project) is 0x70a03. Thus, you should check
for 0x70a03 instead of 0x70f05.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: use correct mime type even if filename has multiple dots.
From: Martin Waitz @ 2006-09-19 8:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eej0l8$36t$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
On Sun, Sep 17, 2006 at 10:23:45AM +0200, Jakub Narebski wrote:
> Martin Waitz wrote:
>
> > hoi :)
> >
> > hmm, but it didn't work for me.
> > I had filenames like "man/program.8.html" which got served as
> > "text/html" with the old code.
>
> And why it shouldn't? From the extension it is HTML page, I would guess
> manpage converted to HTML (pretty-printed manpage). And it should be served
> with text/html mimetype.
arg, typo, it got served as "text/plain".
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: more support for PATH_INFO based URLs
From: Martin Waitz @ 2006-09-19 8:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eejlht$870$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
hoi :)
On Sun, Sep 17, 2006 at 04:20:23PM +0200, Jakub Narebski wrote:
> matled (Matthias Lederhofer) on #git proposed to use ':' as a separator
> between branch and filename (as branch doesn't need to be flat,
> e.g. "jc/diff" like branch name), because valid branch name cannot contain
> ':' (and this limit is only for branch name).
you are right, my patch doesn't work with hierarchical branch names.
However using ":" alone does not work eighter.
My main motivation for this patch was to be able to export .html files
and to have working links between them.
However a <a href="main.html"> link inside "branch:index.html" would
try to get "main.html" and not "branch:main.html".
Perhaps use ":/" as separator?
Or try to add more words to the branch name until we get a valid one.
But I don't know how this plays with Linus' latest ref-pack work
where both "a" and "a/b" are valid branch names (If I understood it
correctly). Perhaps use a similiar algorith as the one I used
to get the project path?
> He also said that filename doesn't need to be necessary file (which would be
> then present in "blob_plain" view), but it can be also a directory (which
> then would be present in "tree" view). We can either check type using
> git-cat-file -t via git_get_type subroutine, or assume that if we want for
> directory to be shown, it should end with "/".
yes, this was something I wanted to do later, too.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Patch for http-fetch.c and older curl releases
From: Junio C Hamano @ 2006-09-19 0:37 UTC (permalink / raw)
To: git
In-Reply-To: <20060919003237.GH1261@artsapartment.org>
"Art Haas" <ahaas@airmail.net> writes:
>> Eh, why not
>>
>> #ifndef CURLE_HTTP_RETURNED_ERROR
>> #define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
>> #endif
>
> Hi.
>
> Both 'CURLE_HTTP_RETURNED_ERROR' and 'CURLE_HTTP_NOT_FOUND' are part of
> an enumeration, not preprocessor '#define' values. I suppose that the
> odd-looking 'E' in the names is meant to signify 'enum'.
Ah, sorry I misunderstood the original problem completely.
Then your original patch is _much_ better.
^ permalink raw reply
* Re: Patch for http-fetch.c and older curl releases
From: Art Haas @ 2006-09-19 0:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmcwogp9.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 18, 2006 at 05:14:42PM -0700, Junio C Hamano wrote:
> "Art Haas" <ahaas@airmail.net> writes:
>
> > Here's a patch that does that. I patched 'http.h' as there is already
> > a number of other curl tests in that file. On the machine where the
> > build was failing, the 'curl-config --vernum' returned '070908',
> > and on my home machine where things build without issue the same
> > command returns '070f05', so I took that value to do the comparison.
> > Perhaps an intermediate value would work as well, but I don't have
> > a suitable version to check.
> >
> > Signed-off-by: Art Haas <ahaas@airmail.net>
> >
> > diff --git a/http.h b/http.h
> > index 9ca16ac..aeff988 100644
> > --- a/http.h
> > +++ b/http.h
> > @@ -22,6 +22,10 @@ #if LIBCURL_VERSION_NUM < 0x070c04
> > #define NO_CURL_EASY_DUPHANDLE
> > #endif
> >
> > +#if LIBCURL_VERSION_NUM < 0x070f05
> > +#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> > +#endif
> > +
> > struct slot_results
> > {
> > CURLcode curl_result;
> >
>
> Eh, why not
>
> #ifndef CURLE_HTTP_RETURNED_ERROR
> #define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> #endif
Hi.
Both 'CURLE_HTTP_RETURNED_ERROR' and 'CURLE_HTTP_NOT_FOUND' are part of
an enumeration, not preprocessor '#define' values. I suppose that the
odd-looking 'E' in the names is meant to signify 'enum'.
Art Haas
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply
* Re: Patch for http-fetch.c and older curl releases
From: Junio C Hamano @ 2006-09-19 0:14 UTC (permalink / raw)
To: Art Haas; +Cc: git
In-Reply-To: <20060918235753.GG1261@artsapartment.org>
"Art Haas" <ahaas@airmail.net> writes:
> Here's a patch that does that. I patched 'http.h' as there is already
> a number of other curl tests in that file. On the machine where the
> build was failing, the 'curl-config --vernum' returned '070908',
> and on my home machine where things build without issue the same
> command returns '070f05', so I took that value to do the comparison.
> Perhaps an intermediate value would work as well, but I don't have
> a suitable version to check.
>
> Signed-off-by: Art Haas <ahaas@airmail.net>
>
> diff --git a/http.h b/http.h
> index 9ca16ac..aeff988 100644
> --- a/http.h
> +++ b/http.h
> @@ -22,6 +22,10 @@ #if LIBCURL_VERSION_NUM < 0x070c04
> #define NO_CURL_EASY_DUPHANDLE
> #endif
>
> +#if LIBCURL_VERSION_NUM < 0x070f05
> +#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
> +#endif
> +
> struct slot_results
> {
> CURLcode curl_result;
>
Eh, why not
#ifndef CURLE_HTTP_RETURNED_ERROR
#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
#endif
^ permalink raw reply
* Re: Patch for http-fetch.c and older curl releases
From: Art Haas @ 2006-09-18 23:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pv4pyey.fsf@assigned-by-dhcp.cox.net>
On Mon, Sep 18, 2006 at 04:06:45PM -0700, Junio C Hamano wrote:
> "Art Haas" <ahaas@airmail.net> writes:
>
> > Older curl releases do not define CURLE_HTTP_RETURNED_ERROR, they
> > use CURLE_HTTP_NOT_FOUND instead. The trivial patch below fixes
> > the build error. Newer curl releases keep the CURLE_HTTP_NOT_FOUND
> > definition but using a -DCURL_NO_OLDIES preprocessor flag
> > the old name will not be present in the 'curl.h' header. The
> > comments in 'curl.h' have more info about the name change.
> >
> > Signed-off-by: Art Haas <ahaas@airmail.net>
>
> The patch to use older name in a recent program feels going
> backwards. The header is only trying to be nice so you can
> compile old programs written for older interface that use older
> names. If the new way is the primary way with the new interface,
> and if we are writing a new program, I think we should write for
> the new interface.
>
> Can we have the main code to target the more recent version,
> while working around problems with older versions with backward
> compatibility macros?
>
> In other words, if the macro HTTP_RETURNED_ERROR is not defined
> in the header (i.e. older version), you define it to be the same
> as HTTP_NOT_FOUND.
Hi.
Here's a patch that does that. I patched 'http.h' as there is already
a number of other curl tests in that file. On the machine where the
build was failing, the 'curl-config --vernum' returned '070908',
and on my home machine where things build without issue the same
command returns '070f05', so I took that value to do the comparison.
Perhaps an intermediate value would work as well, but I don't have
a suitable version to check.
Signed-off-by: Art Haas <ahaas@airmail.net>
diff --git a/http.h b/http.h
index 9ca16ac..aeff988 100644
--- a/http.h
+++ b/http.h
@@ -22,6 +22,10 @@ #if LIBCURL_VERSION_NUM < 0x070c04
#define NO_CURL_EASY_DUPHANDLE
#endif
+#if LIBCURL_VERSION_NUM < 0x070f05
+#define CURLE_HTTP_RETURNED_ERROR CURLE_HTTP_NOT_FOUND
+#endif
+
struct slot_results
{
CURLcode curl_result;
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply related
* Re: Patch for http-fetch.c and older curl releases
From: Junio C Hamano @ 2006-09-18 23:06 UTC (permalink / raw)
To: Art Haas; +Cc: git
In-Reply-To: <20060918225445.GF1261@artsapartment.org>
"Art Haas" <ahaas@airmail.net> writes:
> Older curl releases do not define CURLE_HTTP_RETURNED_ERROR, they
> use CURLE_HTTP_NOT_FOUND instead. The trivial patch below fixes
> the build error. Newer curl releases keep the CURLE_HTTP_NOT_FOUND
> definition but using a -DCURL_NO_OLDIES preprocessor flag
> the old name will not be present in the 'curl.h' header. The
> comments in 'curl.h' have more info about the name change.
>
> Signed-off-by: Art Haas <ahaas@airmail.net>
The patch to use older name in a recent program feels going
backwards. The header is only trying to be nice so you can
compile old programs written for older interface that use older
names. If the new way is the primary way with the new interface,
and if we are writing a new program, I think we should write for
the new interface.
Can we have the main code to target the more recent version,
while working around problems with older versions with backward
compatibility macros?
In other words, if the macro HTTP_RETURNED_ERROR is not defined
in the header (i.e. older version), you define it to be the same
as HTTP_NOT_FOUND.
^ permalink raw reply
* Patch for http-fetch.c and older curl releases
From: Art Haas @ 2006-09-18 22:54 UTC (permalink / raw)
To: git
Hi.
Older curl releases do not define CURLE_HTTP_RETURNED_ERROR, they
use CURLE_HTTP_NOT_FOUND instead. The trivial patch below fixes
the build error. Newer curl releases keep the CURLE_HTTP_NOT_FOUND
definition but using a -DCURL_NO_OLDIES preprocessor flag
the old name will not be present in the 'curl.h' header. The
comments in 'curl.h' have more info about the name change.
Signed-off-by: Art Haas <ahaas@airmail.net>
diff --git a/http-fetch.c b/http-fetch.c
index bc74f30..76fcdc7 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -149,7 +149,7 @@ static int missing__target(int code, int
return /* file:// URL -- do we ever use one??? */
(result == CURLE_FILE_COULDNT_READ_FILE) ||
/* http:// and https:// URL */
- (code == 404 && result == CURLE_HTTP_RETURNED_ERROR) ||
+ (code == 404 && result == CURLE_HTTP_NOT_FOUND) ||
/* ftp:// URL */
(code == 550 && result == CURLE_FTP_COULDNT_RETR_FILE)
;
--
Man once surrendering his reason, has no remaining guard against absurdities
the most monstrous, and like a ship without rudder, is the sport of every wind.
-Thomas Jefferson to James Smith, 1822
^ permalink raw reply related
* [PATCH] fsck-objects: adjust to resolve_ref() clean-up.
From: Junio C Hamano @ 2006-09-18 18:44 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
Clean-up the same "ref to path and then back to ref" confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
fsck-objects.c | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/fsck-objects.c b/fsck-objects.c
index 4d994f3..456c17e 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -458,15 +458,13 @@ static void fsck_object_dir(const char *
static int fsck_head_link(void)
{
unsigned char sha1[20];
- const char *git_HEAD = xstrdup(git_path("HEAD"));
- const char *git_refs_heads_master = resolve_ref(git_HEAD, sha1, 1);
- int pfxlen = strlen(git_HEAD) - 4; /* strip .../.git/ part */
+ const char *head_points_at = resolve_ref("HEAD", sha1, 1);
- if (!git_refs_heads_master)
+ if (!head_points_at)
return error("HEAD is not a symbolic ref");
- if (strncmp(git_refs_heads_master + pfxlen, "refs/heads/", 11))
+ if (strncmp(head_points_at, "refs/heads/", 11))
return error("HEAD points to something strange (%s)",
- git_refs_heads_master + pfxlen);
+ head_points_at);
if (is_null_sha1(sha1))
return error("HEAD: not a valid git pointer");
return 0;
--
1.4.2.1.g01ff
^ permalink raw reply related
* Re: [RFC] git-pack-refs --prune
From: Junio C Hamano @ 2006-09-18 18:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609180934360.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The way to fix both these problems at once would be to add a flag to the
> "for_each_ref()", which says whether it followed a link, or whether it was
> already packed, so that we wouldn't pack symlinks at all, and we wouldn't
> add already-packed refs to the "keeprefs" list.
>
> But that requires a sligh semantic extension to "do_for_each_ref()" (and
> "struct ref_list" needs a flag to say whether it was looked up through a
> symlink).
>
> I was thinking that the easy way to solve it is to just _pack_ everything
> (the way we do now - incorrectly for symrefs), but never prune a symref.
I see. Thanks for pointing out the issue with symrefs. I think
clone with --use-separate-remote creates remote/$that_repo/HEAD
that points at the branch the remote side's HEAD points at (to
be precise, the one it guessed the remote side's HEAD points
at), so this is a real issue already.
I wanted to update for_each_ref() anyway for other reasons (it
really should take callback data -- the way the current users
use global variables to work this around is eyesore), so
hopefully I'll find time to take a look at it.
Rough outline:
- for_each_ref() and friends become:
typedef int each_ref_fn(const char *refname,
const unsigned char *sha1,
#define REF_IS_SYMREF 01
#define REF_IS_PACKED 02
int flags, /* above bits or'ed */
void *cb_data);
int for_each_ref(each_ref_fn fn, void *cb_data);
- handle_one_ref notices a symref and ignores it; it remembers
refs that are not symref and are still loose for later
pruning under --prune.
We might want to update the initial handshake of upload-pack
protocol so that peek-remote and fetch-pack can tell which one
is a symref pointing at what. Do the usual server_capabilities
discovery in connect.c::get_remote_heads(), and if an extension
"symref" is supported than ask for symref information (typically
we would only get "HEAD points at refs/heads/foo" and nothing
else). Then git-clone.sh does not have to make a guess. But
that is a separate topic.
^ permalink raw reply
* Re: [PATCH] Remove branch by putting a null sha1 into the ref file.
From: Junio C Hamano @ 2006-09-18 18:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Christian Couder
In-Reply-To: <Pine.LNX.4.64.0609180926590.4388@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Mon, 18 Sep 2006, Christian Couder wrote:
>>
>> With the new packed ref file format from Linus, this should be
>> the new way to remove a branch.
>
> Well, it's not really sufficient.
>
> Somebody should add this test-case
>
> git branch test
> git branch -d test
> git branch test/first
>
> which should work.
Also this test-case needs to be added
git branch test
git pack-refs
rm .git/refs/heads/test
git branch test/second
which should barf. Otherwise it would allow both test and
test/second branches to exist, and trying to clone from such a
repository would fail, at least by the existing tools (it might
have been even nicer if we from day one allowed both test and
test/second to exist, though, but it is too late now, or too
early before we upgrade everybody).
> It's entirely possible that the proper way to do branch deletion with
> packed branches is to simply re-pack without the old branch, rather than
> the negative branch model. I couldn't really decide.
Or mkdir there ,-).
^ permalink raw reply
* Re: Can the git exclude files mask out whole directories?
From: Shawn Pearce @ 2006-09-18 18:32 UTC (permalink / raw)
To: Alex Bennee; +Cc: git
In-Reply-To: <1158604087.28026.160.camel@okra.transitives.com>
Alex Bennee <kernel-hacker@bennee.com> wrote:
> I may be being a bit dim but according to the man page I should be able
> to specify paths with /'s in them. I want to exclude all CVS directories
> so I can commit stuff. I have tried:
>
> #
> # Ignore CVS files
> #
> */CVS/*
Just use CVS in your info/exclude file:
#
# Ignore CVS files
#
CVS
> to my exclude file but that seems suboptimal. Besides I'll also want to
> be ignoring whole build directories later. Have I subtly misunderstood
> the man page?
I ignore my build directories all the time by just putting their
names in .gitignore, with no trailing /.
--
Shawn.
^ permalink raw reply
* Can the git exclude files mask out whole directories?
From: Alex Bennee @ 2006-09-18 18:28 UTC (permalink / raw)
To: git
Hi,
I may be being a bit dim but according to the man page I should be able
to specify paths with /'s in them. I want to exclude all CVS directories
so I can commit stuff. I have tried:
#
# Ignore CVS files
#
*/CVS/*
Amongst many variants and:
git-ls-files --others --exclude-from=.git/info/exclude
And all my CVS directories still get listed. I can get what I want with
adding:
# Ignore CVS files
#
Entries
Entries.Log
Repository
Root
Tag
to my exclude file but that seems suboptimal. Besides I'll also want to
be ignoring whole build directories later. Have I subtly misunderstood
the man page?
Confused,
--
Alex, homepage: http://www.bennee.com/~alex/
Majority, n.: That quality that distinguishes a crime from a law.
^ permalink raw reply
* Re: [PATCH] Contributed bash completion support for core Git tools.
From: Shawn Pearce @ 2006-09-18 17:55 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20060918083114.GQ20913@albany.tokkee.org>
Sebastian Harl <sh@tokkee.org> wrote:
> Hi,
>
> > This is a set of bash completion routines for many of the
> > popular core Git tools. I wrote these routines from scratch
> > after reading the git-compl and git-compl-lib routines available
> > from the gitcompletion package at http://gitweb.hawaga.org.uk/
> > and found those to be lacking in functionality for some commands.
>
> Did you talk to Ben Clifford (the maintainer of these scripts) before?
No. I found his scripts yesterday, played around with them for
about 15 minutes and found them to be missing some features.
In particular they don't actually list all branch names as they
only list only those contained directly in refs/heads. This is
certainly very annoying when your topic branch policy uses "sp/",
"jh/", "lt/" as branch name prefixes. It also won't work with Linus'
new packed ref format...
Ben's scripts also don't always complete tags at points where Git
accepts a tag, nor can they complete through a path with git diff
or git cat-file to yank a file out of another branch which doesn't
exist in the current working directory. They also can't complete
branch names in a remote repository when you are fetching or pushing.
So I set out to write my own, finished it in less than an hour,
used it for 4 hours while doing some merging, and sent an email to
put the script into contrib. :-)
> His scripts seem to be in pretty wide-spread use already, so it might
> make sense to join efforts and improve his scripts (and get them
> into git-core).
Agreed. There may be a few things my script is lacking but I
think the one I sent yesterday is already more powerful than Ben's.
But I'd like to see it be smarter about completion context and do
even more. But right now I'm happy as it can complete my topic
branch names and tag names.
I'd like to see core Git at least carry the completion for core Git.
I know Ben has support for StGit and Cogito as well; two packages
that my script doesn't support. In my humble opnion the completion
scripts should migrate into the packages they support. I don't
think its unreasonable to expect bash completion support to be part
of a popular package which is heavily dependent on the shell for
its user interface[*1*].
> > Consequently there may be some similarities but many differences.
>
> Do you know of any (incompatible) differences?
None that I can think of. I believe that my script will complete
anything Ben's does with the exception of a stray single character
option here or there.
You can't load both into your shell at the same time as bash will
only accept one completion function for any given command and both
packages use the same function names to implement the completion
logic.
[*1*] So long as there is someone to maintain it anyway. :-)
--
Shawn.
^ 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