* Re: gitweb testing with non-apache web server
From: Jakub Narebski @ 2006-08-03 15:48 UTC (permalink / raw)
To: git
In-Reply-To: <20060803153403.GA30729@buici.com>
Marc Singer wrote:
> That isn't enough. I did something like that when I was exploring the
> script. While the change *does* eliminate the 403 error, it doesn't
> make the rest of the script work properly. All of the links return to
> the same page that lists the projects.
Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
links use 'p=$project', not PATH_INFO...
Are you sure you did changes mentioned in earlier post?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Blu Corater @ 2006-08-03 15:56 UTC (permalink / raw)
To: git
In-Reply-To: <20060803075403.GA5238@buici.com>
On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
> I would like to use gitweb with the Cherokee web server because the
> host that I have on hand has very limited RAM, 32MiB. Neither the
> version of gitweb available on Debian (v264) nor the latest in the git
> repo works.
>
> I did some debugging on the latest repo version. The lines
>
> our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> if (defined $project) {
> ...
>
> are being executed even though the url is
>
> http://server/git
>
> I think that the problem is that Cherokee translates the request URL
> into
>
> http://server/git/
>
> which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> being undefined.
>
> The error I'm seeing is that the request path is forbidden, but I
> suspect that this is some sort of misunderstanding between the web
> server and the script.
I am using Cherokee+GitWeb and the behaviour observed is that
http://server/git will return the default Cherokee index page, but
http://server/git/, with a slash at the end, works.
--
Blu.
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Marc Singer @ 2006-08-03 16:20 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eat5qp$3sr$1@sea.gmane.org>
On Thu, Aug 03, 2006 at 05:48:11PM +0200, Jakub Narebski wrote:
> Marc Singer wrote:
>
> > That isn't enough. I did something like that when I was exploring the
> > script. While the change *does* eliminate the 403 error, it doesn't
> > make the rest of the script work properly. All of the links return to
> > the same page that lists the projects.
>
> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
> links use 'p=$project', not PATH_INFO...
>
> Are you sure you did changes mentioned in earlier post?
Yes. I think that there is something else awry as well. Note that
with the change you suggested, the latest script functions at the same
level as the latest from the repo.
TBPH, I've never found a good way to debug CGI scripts. I just want
to see what is going on and that's hard considering the fact that the
server behavior seems to be a crucial component. When I run the
script stand-alone, I see the results I expect (with some errors about
the CGI object missing some parameters).
>
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> 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: gitweb testing with non-apache web server
From: Marc Singer @ 2006-08-03 16:22 UTC (permalink / raw)
To: git
In-Reply-To: <20060803155603.GS7533@daga.cl>
On Thu, Aug 03, 2006 at 11:56:03AM -0400, Blu Corater wrote:
> On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
> > I would like to use gitweb with the Cherokee web server because the
> > host that I have on hand has very limited RAM, 32MiB. Neither the
> > version of gitweb available on Debian (v264) nor the latest in the git
> > repo works.
> >
> > I did some debugging on the latest repo version. The lines
> >
> > our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> > if (defined $project) {
> > ...
> >
> > are being executed even though the url is
> >
> > http://server/git
> >
> > I think that the problem is that Cherokee translates the request URL
> > into
> >
> > http://server/git/
> >
> > which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> > being undefined.
> >
> > The error I'm seeing is that the request path is forbidden, but I
> > suspect that this is some sort of misunderstanding between the web
> > server and the script.
>
> I am using Cherokee+GitWeb and the behaviour observed is that
> http://server/git will return the default Cherokee index page, but
> http://server/git/, with a slash at the end, works.
Will you share your Cherokee configuration script?
The links look like this:
http://scarlet/g?p=bsp.git;a=summary
even when I start with
http://scarlet/g
or
http://scarlet/g/
So, I'm not sure I understand what you are saying.
>
> --
> Blu.
> -
> 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] gitweb.cgi: Customization
From: Jeff King @ 2006-08-03 16:24 UTC (permalink / raw)
To: Martin Waitz
Cc: Martin Langhoff, Junio C Hamano, Luben Tuikov, git,
Matthias Lederhofer
In-Reply-To: <20060803065852.GH16364@admingilde.org>
On Thu, Aug 03, 2006 at 08:58:52AM +0200, Martin Waitz wrote:
> we could make the default use %ENV.
>
> Something like (in Makefile):
>
> GITWEB_SITENAME = $$ENV{GITWEB_SITENAME}
> GITWEB_PROJECTROOT = $$ENV{GITWEB_SITENAME} || "/pub/git"
An interesting idea, but it means that gitweb.perl no longer parses as
valid perl, since we have things like:
> our $projectroot = @@GITWEB_PROJECTROOT@@;
Do the environment variable names really need to be configurable, or
would something like this work:
1. accept from config file if it exists and defines $projectroot
2. otherwise, accept from environment if GITWEB_PROJECTROOT is defined
3. otherwise, default to compile-time value
Speaking of which, perhaps we should clean up the names of variables
that are used by the config file now, before they get into widespread
use. The names are very inconsistent (e.g., projectroot, git_temp) and
undocumented. We could standardize on something like
$GITWEB_PROJECTROOT, matched to GITWEB_PROJECTROOT in the environment
and GITWEB_PROJECTROOT in the Makefile.
-Peff
^ permalink raw reply
* Regression: git-commit no longer works from within subdirectories
From: Robert Shearman @ 2006-08-03 18:06 UTC (permalink / raw)
To: Git Mailing List
Hi,
In the latest master branch git-commit no longer works from within
subdirectories. Instead, you have to go to the top-level directory of
the git tree to do the commit.
It fails with a confusing message when you are in a subdirectory:
rob@saturn:~/wine-git/dlls/msi$ git commit action.c
usage: git-read-tree (<sha> | [[-m [--aggressive] | --reset |
--prefix=<prefix>] [-u | -i]] <sha1> [<sha2> [<sha3>]])
I'm not sure whether the previous behaviour was intentional, but I got
used to it. Either way, I don't think users upgrading from 1.4.1 would
appreciate a user-facing change like this in a 0.0.1 incremental release.
Can this be changed back to the previous behaviour?
Thanks,
--
Rob Shearman
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Junio C Hamano @ 2006-08-03 18:21 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <eat5qp$3sr$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Marc Singer wrote:
>
>> That isn't enough. I did something like that when I was exploring the
>> script. While the change *does* eliminate the 403 error, it doesn't
>> make the rest of the script work properly. All of the links return to
>> the same page that lists the projects.
>
> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
> links use 'p=$project', not PATH_INFO...
>
> Are you sure you did changes mentioned in earlier post?
Well, more importantly, why would we do something like this in the first
place?
Wouldn't it be a lot better to just rip out PATH_INFO stuff,
especially since all pages the script generates use ?p=$project
to pass that information around and never uses PATH_INFO?
^ permalink raw reply
* Re: Creating diffs
From: Junio C Hamano @ 2006-08-03 18:22 UTC (permalink / raw)
To: Rocco Rutte; +Cc: git
In-Reply-To: <20060803122937.GI5016@robert.daprodeges.fqdn.th-h.de>
Rocco Rutte <pdmef@gmx.net> writes:
> Also, I think the diffs are reversed:
Yeah, I noticed that too.
^ permalink raw reply
* RE: [PATCH 9/10] Remove cmd_usage() routine and re-organize the help/usage code.
From: Ramsay Jones @ 2006-08-03 18:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pwvuhlo.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2984 bytes --]
On Wed 2006-08-02 at 19:18, Junio C Hamano wrote:
>
> Martin Waitz <tali@admingilde.org> writes:
>
> > On Wed, Aug 02, 2006 at 02:03:44AM +0100, Ramsay Jones wrote:
> >> builtin-help.c | 54
> >> +++++++++++++++++++++++-------------------------------
> >> builtin.h | 7 ++-----
> >> git.c | 7 +++++--
> >> 3 files changed, 30 insertions(+), 38 deletions(-)
> >
> > this patch is at the tip of "master" now, but with one more change:
> >...
> > diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
> > index bf1d638..34a3ccd 100755
> > --- a/t/t9100-git-svn-basic.sh
> > +++ b/t/t9100-git-svn-basic.sh
> >...
> > this looks strange.
>
> Ramsay's patch to cmd_help() broke this test because the test
> relied on the details of output from "git help", which the patch
> subtly changed.
>
> I considered making the fix for broken test a separate commit,
> but the fix for the test was simple enough, so I rolled it in,
> with the additional comment in the log to explain what was going
> on -- I suspect the explanation was not clear enough.
>
> I could have committed the fix for the test first and then this
> one.
>
I was surprised and concerned to read that (how did I miss the
failing test?), until I found that I didn't have this test! (Phew)
I assume this is a post 1.4.1 test, and from the name, I suppose
they would have mostly failed for me anyway since I don't have
svn installed.
In any event, I'm sorry to have broken your test, I should have
documented the changed behaviour. The change should be limited to
a lower-case usage prefix and a change in exit code from 1 to 129.
The change from "Usage:" to "usage:" was for consistency with every
other command (ignoring the test-delta program). The exit code
change only applies to one of the four original cmd_usage() call
sites; namely the one changed to a usage() call. Hmmm, should
the other three "call sites" change to exit(129) as well?
Any other change in behavior was unintentional. Did I miss
something?
Speaking of consistency, I noticed some inconsistent command
names in various usage strings. I attach a patch (p0011.txt)
for your consideration.
During one of my "grep-fests", I also noticed some calls to
die(usage_string) rather than usage(usage_string). Calling die()
rather than usage() means that a "fatal: " (rather than "usage: ")
prefix is output prior the usage string, and the exit code
is 128 (rather than 129).
It looks like to choice of die() was deliberate, particularly in
builtin-rm.c and hash-object.c since they call both die() and
usage(). However, It's not clear to me why this choice was made.
(Which is not to say there isn't a perfectly good reason for the
choice; it's just that I don't see it.)
I attach a patch (p0012.txt) which replaces these calls to die()
with usage(). Since it is possible, however unlikely, that there
are some scripts out there that depend on the current behavior,
you may not want to apply it.
Cheers,
Ramsay
[-- Attachment #2: P0011.TXT --]
[-- Type: text/plain, Size: 2727 bytes --]
From 564d11cd55388f6a8de82b34b362543f73e0096c Mon Sep 17 00:00:00 2001
From: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Date: Thu, 3 Aug 2006 16:38:39 +0100
Subject: [PATCH] Fixup command names in some usage strings.
Most usage strings, such as for command xxx, start with "git-xxx".
This updates the rebels to conform to the general pattern.
(The git wrapper is an exception to this, of course ...)
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
---
blame.c | 2 +-
builtin-diff.c | 2 +-
builtin-push.c | 2 +-
mktag.c | 2 +-
mktree.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/blame.c b/blame.c
index c86e2fd..2f19b4d 100644
--- a/blame.c
+++ b/blame.c
@@ -20,7 +20,7 @@ #include "xdiff-interface.h"
#define DEBUG 0
-static const char blame_usage[] = "[-c] [-l] [-t] [-S <revs-file>] [--] file [commit]\n"
+static const char blame_usage[] = "git-blame [-c] [-l] [-t] [-S <revs-file>] [--] file [commit]\n"
" -c, --compability Use the same output mode as git-annotate (Default: off)\n"
" -l, --long Show long commit SHA1 (Default: off)\n"
" -t, --time Show raw timestamp (Default: off)\n"
diff --git a/builtin-diff.c b/builtin-diff.c
index 99a2f76..f934dc0 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -23,7 +23,7 @@ struct blobinfo {
};
static const char builtin_diff_usage[] =
-"diff <options> <rev>{0,2} -- <path>*";
+"git-diff <options> <rev>{0,2} -- <path>*";
static int builtin_diff_files(struct rev_info *revs,
int argc, const char **argv)
diff --git a/builtin-push.c b/builtin-push.c
index 66b9407..57db489 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -8,7 +8,7 @@ #include "builtin.h"
#define MAX_URI (16)
-static const char push_usage[] = "git push [--all] [--tags] [--force] <repository> [<refspec>...]";
+static const char push_usage[] = "git-push [--all] [--tags] [--force] <repository> [<refspec>...]";
static int all = 0, tags = 0, force = 0, thin = 1;
static const char *execute = NULL;
diff --git a/mktag.c b/mktag.c
index be41513..1d0cb17 100644
--- a/mktag.c
+++ b/mktag.c
@@ -123,7 +123,7 @@ int main(int argc, char **argv)
unsigned char result_sha1[20];
if (argc != 1)
- usage("cat <signaturefile> | git-mktag");
+ usage("git-mktag < signaturefile");
setup_git_directory();
diff --git a/mktree.c b/mktree.c
index ab63cd9..9a6f0d2 100644
--- a/mktree.c
+++ b/mktree.c
@@ -71,7 +71,7 @@ static void write_tree(unsigned char *sh
write_sha1_file(buffer, offset, tree_type, sha1);
}
-static const char mktree_usage[] = "mktree [-z]";
+static const char mktree_usage[] = "git-mktree [-z]";
int main(int ac, char **av)
{
--
1.4.1
[-- Attachment #3: P0012.TXT --]
[-- Type: text/plain, Size: 2649 bytes --]
From d5c3c850036f06c35416b8a515652c248bf4a73a Mon Sep 17 00:00:00 2001
From: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
Date: Thu, 3 Aug 2006 16:48:41 +0100
Subject: [PATCH] Replace some calls to die(usage_str) with usage(usage_str).
The only change in behaviour should be having a "usage: " prefix
on the output string rather than "fatal: ", and an exit code of
129 rather than 128.
Signed-off-by: Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
---
builtin-add.c | 2 +-
builtin-init-db.c | 2 +-
builtin-rm.c | 2 +-
builtin-write-tree.c | 2 +-
hash-object.c | 4 ++--
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index bfbbb1b..ced84ea 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -158,7 +158,7 @@ int cmd_add(int argc, const char **argv,
verbose = 1;
continue;
}
- die(builtin_add_usage);
+ usage(builtin_add_usage);
}
git_config(git_default_config);
pathspec = get_pathspec(prefix, argv + i);
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 7fdd2fa..85a2afd 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -267,7 +267,7 @@ int cmd_init_db(int argc, const char **a
else if (!strncmp(arg, "--shared=", 9))
shared_repository = git_config_perm("arg", arg+9);
else
- die(init_db_usage);
+ usage(init_db_usage);
}
/*
diff --git a/builtin-rm.c b/builtin-rm.c
index 4d56a1f..bfacbb2 100644
--- a/builtin-rm.c
+++ b/builtin-rm.c
@@ -81,7 +81,7 @@ int cmd_rm(int argc, const char **argv,
force = 1;
continue;
}
- die(builtin_rm_usage);
+ usage(builtin_rm_usage);
}
if (argc <= i)
usage(builtin_rm_usage);
diff --git a/builtin-write-tree.c b/builtin-write-tree.c
index 70e9b6f..bbe1f07 100644
--- a/builtin-write-tree.c
+++ b/builtin-write-tree.c
@@ -74,7 +74,7 @@ int cmd_write_tree(int argc, const char
else if (!strncmp(arg, "--prefix=", 9))
prefix = arg + 9;
else
- die(write_tree_usage);
+ usage(write_tree_usage);
argc--; argv++;
}
diff --git a/hash-object.c b/hash-object.c
index 43bd93b..bf0b492 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -46,7 +46,7 @@ int main(int argc, char **argv)
if (!no_more_flags && argv[i][0] == '-') {
if (!strcmp(argv[i], "-t")) {
if (argc <= ++i)
- die(hash_object_usage);
+ usage(hash_object_usage);
type = argv[i];
}
else if (!strcmp(argv[i], "-w")) {
@@ -66,7 +66,7 @@ int main(int argc, char **argv)
hash_stdin(type, write_object);
}
else
- die(hash_object_usage);
+ usage(hash_object_usage);
}
else {
const char *arg = argv[i];
--
1.4.1
^ permalink raw reply related
* Re: gitweb testing with non-apache web server
From: Jakub Narebski @ 2006-08-03 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vfygdr888.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>>
>> Strange... PATH_INFO is used _only_ if 'p' parameter is not set. And all
>> links use 'p=$project', not PATH_INFO...
>>
>> Are you sure you did changes mentioned in earlier post?
>
> Well, more importantly, why would we do something like this in the first
> place?
>
> Wouldn't it be a lot better to just rip out PATH_INFO stuff,
> especially since all pages the script generates use ?p=$project
> to pass that information around and never uses PATH_INFO?
The PATH_INFO is here because it is easier to edit parameters by hand when
the most important one, the project to examine, can be passed as PATH_INFO.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] fix git-revert command-line options
From: Martin Waitz @ 2006-08-03 18:41 UTC (permalink / raw)
To: Michael; +Cc: git
In-Reply-To: <20060803153742.109978@dial-up-mi-12.lombardiacom.it>
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
hoi :)
On Thu, Aug 03, 2006 at 05:42:23PM +0200, Michael wrote:
> - -n|--n|--no|--no-|--no-c|--no-co|--no-com|--no-comm|\
> + -n|--no-c|--no-co|--no-com|--no-comm|\
> - --n|--no|--no-|--no-e|--no-ed|--no-edi|--no-edit)
> + --n|--no-e|--no-ed|--no-edi|--no-edit)
well spottet, but now we still have "-n" versus "--n".
Perhaps we should drop the single-letter options or at least only
keep one of them and then explicitly document that in the manpage.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Creating diffs
From: Junio C Hamano @ 2006-08-03 18:45 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <easqpi$o51$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> If I remember correctly there were two patches which solved it differently:
> one gave
>
> --- a/source:file
> +++ b/dest:file
>
> second (and I guess it is better solution)
>
> --- a/file
> +++ b/file
>
> Unfortunately they seem unapplied...
I think I explained why it was not enough in a neighboring
thread. You would need to defeat the rename classification done
in diff.c::diff_resolve_rename_copy().
The diff reversal is independent. I think it was introduced by
mistake when we switched revision.c::add_pending_object() to use
object_array from object_list.
Here is a patch to fix the reversal (swapping of indices for
blob[].sha1 in builtin-diff.c), show both names (swapping of
indices for blob[].name in builtin-diff.c), and not mistake this
as an rename (all the rest). The change touches rather delicate
parts of the system, so I am reluctant to do the latter two at
this late in the game for 1.4.2, but please do test it and give
feedback.
---
diff --git a/builtin-diff.c b/builtin-diff.c
index 48d2fd0..cb4216e 100644
--- a/builtin-diff.c
+++ b/builtin-diff.c
@@ -125,9 +125,6 @@ static int builtin_diff_blobs(struct rev
int argc, const char **argv,
struct blobinfo *blob)
{
- /* Blobs: the arguments are reversed when setup_revisions()
- * picked them up.
- */
unsigned mode = canon_mode(S_IFREG | 0644);
if (argc > 1)
@@ -135,8 +132,8 @@ static int builtin_diff_blobs(struct rev
stuff_change(&revs->diffopt,
mode, mode,
- blob[1].sha1, blob[0].sha1,
- blob[0].name, blob[0].name);
+ blob[0].sha1, blob[1].sha1,
+ blob[0].name, blob[1].name);
diffcore_std(&revs->diffopt);
diff_flush(&revs->diffopt);
return 0;
diff --git a/diff.c b/diff.c
index 607c357..895c137 100644
--- a/diff.c
+++ b/diff.c
@@ -1786,13 +1786,9 @@ struct diff_filepair *diff_queue(struct
struct diff_filespec *one,
struct diff_filespec *two)
{
- struct diff_filepair *dp = xmalloc(sizeof(*dp));
+ struct diff_filepair *dp = xcalloc(1, sizeof(*dp));
dp->one = one;
dp->two = two;
- dp->score = 0;
- dp->status = 0;
- dp->source_stays = 0;
- dp->broken_pair = 0;
if (queue)
diff_q(queue, dp);
return dp;
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 1de8d32..0ec488a 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -205,6 +205,7 @@ static void record_rename_pair(int dst_i
fill_filespec(two, dst->sha1, dst->mode);
dp = diff_queue(NULL, one, two);
+ dp->renamed_pair = 1;
if (!strcmp(src->path, dst->path))
dp->score = rename_src[src_index].score;
else
diff --git a/diffcore.h b/diffcore.h
index 73c7842..2249bc2 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -53,11 +53,12 @@ struct diff_filepair {
char status; /* M C R N D U (see Documentation/diff-format.txt) */
unsigned source_stays : 1; /* all of R/C are copies */
unsigned broken_pair : 1;
+ unsigned renamed_pair : 1;
};
#define DIFF_PAIR_UNMERGED(p) \
(!DIFF_FILE_VALID((p)->one) && !DIFF_FILE_VALID((p)->two))
-#define DIFF_PAIR_RENAME(p) (strcmp((p)->one->path, (p)->two->path))
+#define DIFF_PAIR_RENAME(p) ((p)->renamed_pair)
#define DIFF_PAIR_BROKEN(p) \
( (!DIFF_FILE_VALID((p)->one) != !DIFF_FILE_VALID((p)->two)) && \
^ permalink raw reply related
* Re: Regression: git-commit no longer works from within subdirectories
From: Junio C Hamano @ 2006-08-03 19:05 UTC (permalink / raw)
To: Robert Shearman; +Cc: git
In-Reply-To: <44D23B1C.80704@codeweavers.com>
Robert Shearman <rob@codeweavers.com> writes:
> In the latest master branch git-commit no longer works from within
> subdirectories. Instead, you have to go to the top-level directory of
> the git tree to do the commit.
This is broken and sorry I did not notice it earlier because I
usually run the tip of "next". Will take a look.
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Blu Corater @ 2006-08-03 19:21 UTC (permalink / raw)
To: git
In-Reply-To: <20060803162241.GB1287@buici.com>
On Thu, Aug 03, 2006 at 09:22:41AM -0700, Marc Singer wrote:
> On Thu, Aug 03, 2006 at 11:56:03AM -0400, Blu Corater wrote:
> > On Thu, Aug 03, 2006 at 12:54:03AM -0700, Marc Singer wrote:
> > > I would like to use gitweb with the Cherokee web server because the
> > > host that I have on hand has very limited RAM, 32MiB. Neither the
> > > version of gitweb available on Debian (v264) nor the latest in the git
> > > repo works.
> > >
> > > I did some debugging on the latest repo version. The lines
> > >
> > > our $project = ($cgi->param('p') || $ENV{'PATH_INFO'});
> > > if (defined $project) {
> > > ...
> > >
> > > are being executed even though the url is
> > >
> > > http://server/git
> > >
> > > I think that the problem is that Cherokee translates the request URL
> > > into
> > >
> > > http://server/git/
> > >
> > > which means that the $ENV{'PATH_INFO'} is the string "/" insted of
> > > being undefined.
> > >
> > > The error I'm seeing is that the request path is forbidden, but I
> > > suspect that this is some sort of misunderstanding between the web
> > > server and the script.
> >
> > I am using Cherokee+GitWeb and the behaviour observed is that
> > http://server/git will return the default Cherokee index page, but
> > http://server/git/, with a slash at the end, works.
>
> Will you share your Cherokee configuration script?
>
> The links look like this:
>
> http://scarlet/g?p=bsp.git;a=summary
>
> even when I start with
>
> http://scarlet/g
>
> or
>
> http://scarlet/g/
>
> So, I'm not sure I understand what you are saying.
Here is the interesting part of my cherokee.conf
------------------------------------------
UserDir public_html {
Directory / {
Handler common
}
Directory /scm/ {
Handler cgi {
ScriptAlias /home/blu/bin/gitweb.cgi
}
}
}
-----------------------------------------
So, I have the gitweb.cgi executable in a bin directory on my home and I
am telling Cherokee that when it sees the url http://server/~blu/scm/, it
should execute /home/blu/bin/gitweb.cgi
If I request http://server/~blu/scm, Cherokee returns Cherokee's default
index page. Only if I request http://server/~blu/scm/, Cherokee returns
the expected output from gitweb.
Now, if I add
Directory /test/ {
Handler cgi
}
And copy gitweb.cgi to ~/public_html/test/, it seems there is no problem.
I can request http://server/~blu/test/gitweb.cgi or
http://server/~blu/test/gitweb.cgi/ and get the expected gitweb output.
It looks more like a Cherokee problem to me, but I don't have time to
investigate further right now.
--
Blu.
^ permalink raw reply
* Re: [PATCH 9/10] Remove cmd_usage() routine and re-organize the help/usage code.
From: Junio C Hamano @ 2006-08-03 19:30 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, git
In-Reply-To: <000101c6b72a$51601a80$c47eedc1@ramsay1.demon.co.uk>
"Ramsay Jones" <ramsay@ramsay1.demon.co.uk> writes:
> In any event, I'm sorry to have broken your test,
Don't worry. My primary function while wearing the "maintainer"
hat is to catch mistakes like this; even if this test breakage
slipped through, it would not have been your fault but mine.
> ... I should have
> documented the changed behaviour. The change should be limited to
> a lower-case usage prefix and a change in exit code from 1 to 129.
I think both are good changes. The native usage() exits with 129
so it would be consistent for the git wrapper to exit with 129
when it gives usage message, and in lowercase.
Will take a look at your patches when I go home (I am at day-job
today).
^ permalink raw reply
* Re: [PATCH] fix git-revert command-line options
From: Junio C Hamano @ 2006-08-03 19:31 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060803184141.GA5476@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Thu, Aug 03, 2006 at 05:42:23PM +0200, Michael wrote:
>> - -n|--n|--no|--no-|--no-c|--no-co|--no-com|--no-comm|\
>> + -n|--no-c|--no-co|--no-com|--no-comm|\
>
>> - --n|--no|--no-|--no-e|--no-ed|--no-edi|--no-edit)
>> + --n|--no-e|--no-ed|--no-edi|--no-edit)
>
> well spottet, but now we still have "-n" versus "--n".
> Perhaps we should drop the single-letter options or at least only
> keep one of them and then explicitly document that in the manpage.
Good suggestion.
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Junio C Hamano @ 2006-08-03 19:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eatfog$8er$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Well, more importantly, why would we do something like this in the first
>> place?
>>
>> Wouldn't it be a lot better to just rip out PATH_INFO stuff,
>> especially since all pages the script generates use ?p=$project
>> to pass that information around and never uses PATH_INFO?
>
> The PATH_INFO is here because it is easier to edit parameters by hand when
> the most important one, the project to examine, can be passed as PATH_INFO.
Huh? I do not get that.
Suppose I am looking at my repository. I visit there from my
Firefox and see this in the location bar:
http://www.kernel.org/git/?p=git/git.git;a=summary
Now I would want to check if there are updates to gitk. So I
click on the location bar, and edit it to:
http://www.kernel.org/git/?p=gitk/gitk.git;a=summary
(that's two insertions of 'k').
Now with PATH_INFO, how exactly is this easier?
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Martin Waitz @ 2006-08-03 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7virl9ppy7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]
hoi :)
On Thu, Aug 03, 2006 at 12:41:20PM -0700, Junio C Hamano wrote:
> http://www.kernel.org/git/?p=gitk/gitk.git;a=summary
>
> (that's two insertions of 'k').
>
> Now with PATH_INFO, how exactly is this easier?
well, editing is not easier, but you can do other nice things.
On git.admingilde.org I have set up apache to serve the contents
of my git repositories for all the well-known git repository
URLs (*.git/objects/*, *.git/refs/*, ...) and to call gitweb for
all other URLs.
That way I get the exact same URLs for both gitweb and http:// clone
(and even for git://, just change the protocol name).
I really think that it is very handy that you can give out a
repository URL and any user can just click on it and get the
summary page of this project.
I'm sure that it is possible to transfer the PATH_INFO into a p=
parameter through URL rewrite rules, but it is much easier
to set up if gitweb can directly grok appended paths.
I even changed the old gitweb to hand out links which used PATH_INFO
rather than the p= parameter so that the URLs looked nicer.
If there is interest in such a feature then I can do these changes
again.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: gitweb testing with non-apache web server
From: Marc Singer @ 2006-08-03 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060803192152.GT7533@daga.cl>
On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
> Here is the interesting part of my cherokee.conf
>
> ------------------------------------------
> UserDir public_html {
> Directory / {
> Handler common
> }
>
> Directory /scm/ {
> Handler cgi {
> ScriptAlias /home/blu/bin/gitweb.cgi
> }
> }
> }
> -----------------------------------------
>
> So, I have the gitweb.cgi executable in a bin directory on my home and I
> am telling Cherokee that when it sees the url http://server/~blu/scm/, it
> should execute /home/blu/bin/gitweb.cgi
>
> If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> index page. Only if I request http://server/~blu/scm/, Cherokee returns
> the expected output from gitweb.
>
> Now, if I add
>
> Directory /test/ {
> Handler cgi
> }
>
> And copy gitweb.cgi to ~/public_html/test/, it seems there is no problem.
>
> I can request http://server/~blu/test/gitweb.cgi or
> http://server/~blu/test/gitweb.cgi/ and get the expected gitweb output.
>
> It looks more like a Cherokee problem to me, but I don't have time to
> investigate further right now.
Hmm. I was hopeful when I saw that your configuration was different
from mine. However, it seems to be something else. BTW, I'm running
cherokee on ARM.
========================================
Directory / {
Handler common
}
Directory /g/ {
Handler cgi {
Scriptalias /usr/lib/cgi-bin/git.cgi
}
}
Directory /git/ {
Handler cgi {
Scriptalias /usr/lib/cgi-bin/gitweb.cgi
}
}
========================================
gitweb.cgi is an old version. git.cgi is the latest release.
I can see the project overview page, but all of the links bring me
back to the same top-level page, no summary, not logs. I've verified
that the web server's user can read the git repo.
I don't doubt that this is a cherokee issue.
Cheers.
^ permalink raw reply
* Re: Regression: git-commit no longer works from within subdirectories
From: Jeff King @ 2006-08-03 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert Shearman, Git Mailing List
In-Reply-To: <44D23B1C.80704@codeweavers.com>
On Thu, Aug 03, 2006 at 07:06:20PM +0100, Robert Shearman wrote:
> It fails with a confusing message when you are in a subdirectory:
> rob@saturn:~/wine-git/dlls/msi$ git commit action.c
> usage: git-read-tree (<sha> | [[-m [--aggressive] | --reset |
> --prefix=<prefix>] [-u | -i]] <sha1> [<sha2> [<sha3>]])
The culprit is the recent changes to the builtins. cmd_read_tree now
takes an extra parameter 'prefix' which shadows the global declaration
in builtin-read-tree.c (and has a completely different meaning).
The one-liner below fixes it (though style-wise, you may prefer to rename the
shadowed variable).
-Peff
---
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 49c10bf..8e3b04e 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -870,7 +870,7 @@ static const char read_tree_usage[] = "g
static struct lock_file lock_file;
-int cmd_read_tree(int argc, const char **argv, const char *prefix)
+int cmd_read_tree(int argc, const char **argv, const char *git_prefix)
{
int i, newfd, stage = 0;
unsigned char sha1[20];
^ permalink raw reply related
* git-annotate bug report
From: Jeff King @ 2006-08-03 20:38 UTC (permalink / raw)
To: ryan; +Cc: git
git-annotate on the tip of master seems to be broken for some files (but
not for others):
$ git-describe
v1.4.2-rc2-gfba0cbd
$ make && ./git-annotate builtin-read-tree.c
parent eff97e3faeb28f6521851c1b3be1a54a2138f12a is on line 852
Line 852, does not match:
||
| cnt++;|
021b6e454944a4fba878651ebf9bfe0a3f6c3077
-Peff
^ permalink raw reply
* Re: [PATCH] fix git-revert command-line options
From: Michael @ 2006-08-03 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Waitz
In-Reply-To: <7vmzalpqdt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
> > On Thu, Aug 03, 2006 at 05:42:23PM +0200, Michael wrote:
> >> - -n|--n|--no|--no-|--no-c|--no-co|--no-com|--no-comm|\
> >> + -n|--no-c|--no-co|--no-com|--no-comm|\
> >>
> >> - --n|--no|--no-|--no-e|--no-ed|--no-edi|--no-edit)
> >> + --n|--no-e|--no-ed|--no-edi|--no-edit)
> >
> > well spottet, but now we still have "-n" versus "--n".
> > Perhaps we should drop the single-letter options or at least only
> > keep one of them and then explicitly document that in the manpage.
>
> Good suggestion.
Well, I left "--n" for the lazy typers, but it's too confusing - and
can be easy misremembered. I'd leave "-n" for "--no-commit", though
(and it's already on man page).
Your choice.
^ permalink raw reply
* Re: git-annotate bug report
From: Ryan Anderson @ 2006-08-03 21:10 UTC (permalink / raw)
To: Jeff King; +Cc: ryan, git
In-Reply-To: <20060803203848.GA15121@coredump.intra.peff.net>
On Thu, Aug 03, 2006 at 04:38:48PM -0400, Jeff King wrote:
> git-annotate on the tip of master seems to be broken for some files (but
> not for others):
>
> $ git-describe
> v1.4.2-rc2-gfba0cbd
> $ make && ./git-annotate builtin-read-tree.c
> parent eff97e3faeb28f6521851c1b3be1a54a2138f12a is on line 852
> Line 852, does not match:
> ||
> | cnt++;|
> 021b6e454944a4fba878651ebf9bfe0a3f6c3077
Sweet, that might be exactly the test case I need to figure out where it
loses track of some lines during merges.
I'll see about looking at this over the weekend.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* [RFC] Introduce git-xxdiff to invoke xxdiff for manual conflict resolution
From: Martin Langhoff @ 2006-08-03 23:53 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
This is a bit of a crude but really useful shortcut for conflict resolution.
The name is bad, but git-merge-* is a different 'namespace', and git-resolve is
also taken.
And as different conflict resolvers take different options, it may make sense
to have git-xxdiff, git-sdiff and git-winmerge at least initially.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
Makefile | 2 +-
git-xxdiff.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 8349e3d..a6f6628 100644
--- a/Makefile
+++ b/Makefile
@@ -145,7 +145,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh git-quiltimport.sh git-xxdiff.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-xxdiff.sh b/git-xxdiff.sh
new file mode 100755
index 0000000..d562ab2
--- /dev/null
+++ b/git-xxdiff.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+USAGE='<path>'
+SUBDIRECTORY_OK=No
+. git-sh-setup
+
+FILE=$1
+MERGE_HEAD=`git rev-parse MERGE_HEAD`
+
+# Sanity checks
+if test ! -n "$FILE"
+then
+ echo Need a path
+ exit 1
+fi
+
+if test ! -n "$MERGE_HEAD"
+then
+ echo git-xxdiff is only useful during a merge
+fi
+
+git cat-file blob HEAD:$FILE > $FILE~HEAD
+if test $? -gt 0
+then
+ echo "Error - maybe $FILE is not tracked by git?"
+ exit
+fi
+echo Written $FILE~HEAD
+
+git cat-file blob $MERGE_HEAD:$FILE > $FILE~MERGE_HEAD
+if test $? -gt 0
+then
+ echo "Error - maybe $FILE is not tracked by git?"
+ exit
+fi
+echo Written $FILE~MERGE_HEAD
+
+xxdiff -wbB --show-merged-pane --merged-filename $FILE~merged $FILE~HEAD $FILE~MERGE_HEAD
\ No newline at end of file
--
1.4.2.rc2.g1869bc-dirty
^ permalink raw reply related
* Re: gitweb testing with non-apache web server
From: Francis Daly @ 2006-08-03 23:55 UTC (permalink / raw)
To: git; +Cc: Blu Corater, Marc Singer
In-Reply-To: <20060803202703.GA13147@buici.com>
> Marc Singer wrote:
> On Thu, Aug 03, 2006 at 03:21:52PM -0400, Blu Corater wrote:
Hi there,
> > If I request http://server/~blu/scm, Cherokee returns Cherokee's default
> > index page. Only if I request http://server/~blu/scm/, Cherokee returns
> > the expected output from gitweb.
This is due to one apparent bug in Cherokee's Directory handling.
> I can see the project overview page, but all of the links bring me
> back to the same top-level page, no summary, not logs. I've verified
> that the web server's user can read the git repo.
And this is due a a different, but arguably related, one. (The 301
handler ignores things it shouldn't.)
> I don't doubt that this is a cherokee issue.
Cherokee's handling of both Directory and Request sections with cgi and
Scriptalias seems a bit funky (in different ways). If you want to use
Cherokee configured this way, you may find it handy to add
$my_uri .= '/';
to your version of gitweb.cgi shortly after it is set -- that should
break most of the generated links in a way that causes them to work with
this server.
$my_url is only used in a few places, but it may be worth doing the same
thing to it too.
Or use a web server which isn't broken in this particular way.
Good luck,
f
--
Francis Daly francis@daoine.org
^ 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