* Re: [PATCH] gitweb fix validating pg (page) parameter
From: Junio C Hamano @ 2006-09-17 21:21 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20060917115245.GA15658@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Currently it is possible to give any string ending with a number as
> page. -1 for example is quite bad (error log shows probably 100
> warnings).
>
> @@ -259,7 +259,7 @@ if (defined $hash_parent_base) {
>
> our $page = $cgi->param('pg');
> if (defined $page) {
> - if ($page =~ m/[^0-9]$/) {
> + if ($page =~ m/[^0-9]/) {
> die_error(undef, "Invalid page parameter");
> }
> }
Are we complaining if $page is not a validly formatted number
here? If so why not
unless ($page =~ /^\d+$/ && 1 <= $page) {
barf(...);
}
???
^ permalink raw reply
* Re: [PATCH] git-repack(1): document --window and --depth
From: Junio C Hamano @ 2006-09-17 21:18 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060917110259.GB1497@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> Copy and pasted from git-pack-objects(1).
I've been fighting the urge to do this myself for a few months
now ;-)
$ git log -S--window -- git-repack.sh
commit ccb365047a1081455b767867f0887e7b4334f9d8
Author: Linus Torvalds <torvalds@osdl.org>
Date: Wed Apr 19 10:05:12 2006 -0700
Allow "git repack" users to specify repacking window/depth
.. but don't even bother documenting it. I don't think any normal person
is supposed to ever really care, but it simplifies testing when you want
to use the "git repack" wrapper rather than forcing you to use the core
programs (which already do support the window/depth arguments, of course).
I will take your patch; I think it is useful to document this.
Thanks.
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: A Large Angry SCM @ 2006-09-17 21:11 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eekb4o$5nj$1@sea.gmane.org>
Jakub Narebski wrote:
> A Large Angry SCM wrote:
>> Jakub Narebski wrote:
>>> A Large Angry SCM wrote:
>>>
>>>> There is no fundamental reason Git can not support partial
>>>> checkouts/working directories. In fact, there is no fundamental reason
>>>> Git can not support operations on partial (sparse?) repositories in both
>>>> space (working content/state, etc.) and time (history); it's just a
>>>> matter of record keeping[*1*]. That isn't how the Linux kernel
>>>> developers want to use their VCS but it _is_ how others want to use
>>>> theirs.
>>> There is perhaps not much trouble with partial checkouts, but there is
>>> problem with partial _commits_, at least for snapshot based SCM
>>> (as opposed to patchset based SCM).
>> By "partial commit" I take it you mean a commit with only partial
>> information about the new (content) state? If so, the missing
>> information about the new state can be assumed to have not changed from
>> the previous recorded state (commit).
>
> That of course assumes that 1) the whole state is recorded somewhere
> (perhaps in the repository); so the partial checkout saves space only if
> repository compress really well, 2) there are no merges outside checked out
> part.
1) The TREE objects leading to the objects that are
added/deleted/changed objects are required. TREEs not leading to the
added/deleted/changed objects are not required, only their IDs. That is
sufficient to commit the changes in a partial checkout.
2) Obviously, only the part checked out can be worked on. If you want to
merge changes to some other part, you will need that part, and possibly
a mergebase.
^ permalink raw reply
* Re: git-repack: Outof memory
From: Nicolas Pitre @ 2006-09-17 21:09 UTC (permalink / raw)
To: Dongsheng Song; +Cc: git
In-Reply-To: <450CA561.9030602@gmail.com>
On Sun, 17 Sep 2006, Dongsheng Song wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all:
>
>
> I'm import from subversion. The problem appears to be git-repack phase using too many memory:
>
> $ git-repack -a -f -d --window=64 --depth=64
Try with that --window=64 argument removed.
Nicolas
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: Jakub Narebski @ 2006-09-17 20:28 UTC (permalink / raw)
To: git
In-Reply-To: <450DA99F.8000009@gmail.com>
A Large Angry SCM wrote:
> Jakub Narebski wrote:
>> A Large Angry SCM wrote:
>>
>>> There is no fundamental reason Git can not support partial
>>> checkouts/working directories. In fact, there is no fundamental reason
>>> Git can not support operations on partial (sparse?) repositories in both
>>> space (working content/state, etc.) and time (history); it's just a
>>> matter of record keeping[*1*]. That isn't how the Linux kernel
>>> developers want to use their VCS but it _is_ how others want to use
>>> theirs.
>>
>> There is perhaps not much trouble with partial checkouts, but there is
>> problem with partial _commits_, at least for snapshot based SCM
>> (as opposed to patchset based SCM).
>
> By "partial commit" I take it you mean a commit with only partial
> information about the new (content) state? If so, the missing
> information about the new state can be assumed to have not changed from
> the previous recorded state (commit).
That of course assumes that 1) the whole state is recorded somewhere
(perhaps in the repository); so the partial checkout saves space only if
repository compress really well, 2) there are no merges outside checked out
part.
Is anybody working on "bind" header and subproject support?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: A Large Angry SCM @ 2006-09-17 20:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eek5l4$kaa$1@sea.gmane.org>
Jakub Narebski wrote:
> A Large Angry SCM wrote:
>
>> There is no fundamental reason Git can not support partial
>> checkouts/working directories. In fact, there is no fundamental reason
>> Git can not support operations on partial (sparse?) repositories in both
>> space (working content/state, etc.) and time (history); it's just a
>> matter of record keeping[*1*]. That isn't how the Linux kernel
>> developers want to use their VCS but it _is_ how others want to use
>> theirs.
>
> There is perhaps not much trouble with partial checkouts, but there is
> problem with partial _commits_, at least for snapshot based SCM (as opposed
> to patchset based SCM).
By "partial commit" I take it you mean a commit with only partial
information about the new (content) state? If so, the missing
information about the new state can be assumed to have not changed from
the previous recorded state (commit).
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: Jakub Narebski @ 2006-09-17 18:55 UTC (permalink / raw)
To: git
In-Reply-To: <450D9847.4080308@gmail.com>
A Large Angry SCM wrote:
> There is no fundamental reason Git can not support partial
> checkouts/working directories. In fact, there is no fundamental reason
> Git can not support operations on partial (sparse?) repositories in both
> space (working content/state, etc.) and time (history); it's just a
> matter of record keeping[*1*]. That isn't how the Linux kernel
> developers want to use their VCS but it _is_ how others want to use
> theirs.
There is perhaps not much trouble with partial checkouts, but there is
problem with partial _commits_, at least for snapshot based SCM (as opposed
to patchset based SCM).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: A Large Angry SCM @ 2006-09-17 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvenm3h9f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>> Junio C Hamano wrote:
>> ...
>>> Having said that, I do not necessarily agree that highly modular
>>> projects would want to put everything in one git repository and
>>> track everything as a whole unit.
>> And yet that's exactly how a lot of developers use CVS. You can argue
>> that some other way is better but when they move from CVS they're
>> looking for continuity of productivity which often means not radically
>> changing how they work. At least in the short term.
>
[...]
> I suspect that everything-under-one-roof approach is coming from
> an observation that:
>
> - with CVS, projects that share the same cvsroot can be updated
> with single 'cvs update' command in a directory close to the
> root.
>
> - with git, if you use multiple repositories checked out at
> right places in the working tree hierarchy, you need to run
> around and say "git checkout" or "git commit" everywhere.
>
> and the latter looks very inconvenient.
>
> But of course the latter is very inconvenient. The current "git
> checkout" nor "git commit" are not such subprojects-aware
> Porcelain commands. But that does not mean you have to house
> everything in the same repository and make partial check-in to
> work. You will be enhancing or replacing the same "git checkout"
> and "git commit" commands to do so anyway.
I used CVS as an example but I've seen the "everything-under-one-roof"
approach, as you put it, used in other VCS' that do work with
changesets. One instance, in particular, has all the source and config
files in a single tree that (I'm told) would take several Gigs of
filesystem space to checkout fully. The codebase is modular to a great
extent but any particular project in it usually required files from a
large number of other projects. There is a lot of automation to find the
required parts for builds and other actions on a project's codebase.
Could this be done with multiple repositories? Yes, but we're talking
hundreds (no exaggeration) and many of those would likely end-up
including a large percentage of the other repositories the way the Git
repository includes the Gitk repository. It could work but their
existing approach already works and is likely better suited for their
codebase. Git can not, currently, do all the things that this
organization wants a VCS to do, working with partial checkouts is a key one.
There is no fundamental reason Git can not support partial
checkouts/working directories. In fact, there is no fundamental reason
Git can not support operations on partial (sparse?) repositories in both
space (working content/state, etc.) and time (history); it's just a
matter of record keeping[*1*]. That isn't how the Linux kernel
developers want to use their VCS but it _is_ how others want to use theirs.
Notes:
[*1*] I'm currently working on determining the minimum requirements
needed to support repositories with partial or sparse history.
^ permalink raw reply
* Re: Setting up Password protected repositories?
From: J. Bruce Fields @ 2006-09-17 16:43 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Shawn Pearce, Junio C Hamano, git
In-Reply-To: <E1GOzP9-0001Fn-G8@jdl.com>
On Sun, Sep 17, 2006 at 11:22:03AM -0500, Jon Loeliger wrote:
> So, like, the other day Shawn Pearce mumbled:
> > Access is controlled by standard UNIX user/group read/write access
> > and ACLs if your OS/filesystem support them. You can also control
> > pushing with an update hook.
>
> OK. I seem to recall a recipe down this line somwhere... Is there
> a current "Best Practices" write up somewhere with these details
> outlined in it?
There's a few sentences in Documentation/cvs-migration.txt, and a little
more in Documentation/howto/update-hook-example.txt
--b.
^ permalink raw reply
* Re: [PATCH] Add virtualization support to git-daemon
From: Jon Loeliger @ 2006-09-17 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvenm4xi6.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
> I have a few stylistic comments but the contents look quite sane
> and fine.
Let me clean it up some and respin.
> > I use an inetd invocation like this example:
> >
> > git stream tcp nowait nobody /usr/bin/git-daemon git-daemon --inetd
> > --verbose --syslog
> > --export-all --interpolated-path=/pub/%H/%D
> > /pub/software /software
> > /pub/www.example.com/software
> > /pub/www.example.org/software
> > /pub
>
> This would be nice to have as an example in the documentation.
Will do.
jdl
^ permalink raw reply
* Re: Setting up Password protected repositories?
From: Jon Loeliger @ 2006-09-17 16:22 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20060917022013.GA7512@spearce.org>
So, like, the other day Shawn Pearce mumbled:
> > >
> > > Or am I missing something deeper?
Hmmm... Maybe _I_ am!...
> > I want git-daemon to serve up the repository.
> > I just want to have it served to people who can
> > supply a password or have an ssh key in place.
>
> Don't use git-daemon.
Say that again? It sounded like you said "Don't use git-daemon."
> Instead create UNIX accounts for the people who need access and if
> you don't want them to actually be able to login set their shell
> to be `git-sh`. This is a special shell-like thing that only lets
> the user push or fetch to any repository they have access to.
Yeah, I think I'm getting it now. Don't use git-daemon, and
instead set up UNIX accounts with git-sh as their shell. That
will let them push and fetch from a repository they can access.
> The URL is a 'git+ssh' style URL and they will use SSH to connect.
Ahhh... Straight ssh to git-sh, no git daemon or HTTP in the mix.
> Access is controlled by standard UNIX user/group read/write access
> and ACLs if your OS/filesystem support them. You can also control
> pushing with an update hook.
OK. I seem to recall a recipe down this line somwhere... Is there
a current "Best Practices" write up somewhere with these details
outlined in it?
So slowly we are clued...
Thanks,
jdl
^ permalink raw reply
* Re: gitweb on OpenBSD (-T not supported on filesystems...)
From: Randal L. Schwartz @ 2006-09-17 15:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eej5qa$i3o$1@sea.gmane.org>
>>>>> "Jakub" == Jakub Narebski <jnareb@gmail.com> writes:
Jakub> I thought that OpenBSD has perhaps distributed some old Perl version that
Jakub> doesn't have -X tests (including -T/-B) on filehandles.
>> When I try the original -T $fd I get:
>>
>> Software error:
>> -T and -B not implemented on filehandles at /var/www/htdocs/git/gitweb.cgi
>> line 1598.
Jakub> So this means that Perl implementation in OpenBSD is flawed.
No, see "perldoc perldiag":
"-T" and "-B" not implemented on filehandles
(F) Perl can't peek at the stdio buffer of filehandles when it
doesn't know about your kind of stdio. You'll have to use a file-
name instead.
So the problem is that OpenBSD has a stdio that is not what the Perl authors
anticipated, because it requires peeking behind official interfaces. Perl
isn't flawed. :)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH] gitweb: more support for PATH_INFO based URLs
From: Jakub Narebski @ 2006-09-17 14:20 UTC (permalink / raw)
To: git
In-Reply-To: <eejhtr$paa$1@sea.gmane.org>
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).
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 "/".
Let's assume for simplicity that empty branch name equals to HEAD branch,
and empty filename equals to top (root) directory of project.
So we would have the following types of path based URLs:
* project overview (summary) page of project
* project/branch shortlog of branch
* project/branch:file file in branch, blob_plain view
* project/branch:dir/ directory listing of dir in branch, tree view
Possible shortcuts:
* project/branch: directory listing of branch, main tree view
* project/:file file in HEAD (raw)
* project/:dir/ directory listing of dir in HEAD
* project/: directory listing of project's HEAD
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] upload-archive: monitor child communication even more carefully.
From: Franck Bui-Huu @ 2006-09-17 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rene Scharfe, Git Mailing List
The current code works like this: if others flags than POLLIN is
raised we assume that (a) something bad happened and the child died or
(b) the child has closed the pipe because it had no more data to send.
For the latter case, we assume wrongly that one call to
process_input() will empty the pipe. Indeed it reads only 16Ko of data
by call and the the pipe capacity can be larger than that (on current
Linux kernel, it is 65536 bytes). Therefore the child can write 32ko
of data, for example, and close the pipe. After that poll will return
POLLIN _and_ POLLHUP and the parent will read only 16ko of data.
This patch forces the parent to empty the pipe as soon as POLLIN is
raised and even if POLLHUP or something else is raised too.
Moreover, some implementations of poll might return POLLRDNORM flag
even if it is non standard.
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com>
---
My own fault.
builtin-upload-archive.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index 115a12d..0596865 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -160,7 +160,8 @@ int cmd_upload_archive(int argc, const c
if (pfd[1].revents & POLLIN)
/* Status stream ready */
process_input(pfd[1].fd, 2);
- if ((pfd[0].revents | pfd[1].revents) == POLLIN)
+ /* Always finish to read data when available */
+ if ((pfd[0].revents | pfd[1].revents) & POLLIN)
continue;
if (waitpid(writer, &status, 0) < 0)
--
1.4.2.1.gcd6f1-dirty
^ permalink raw reply related
* [PATCH] gitweb: fix warnings in PATH_INFO code and add export_ok/strict_export
From: Matthias Lederhofer @ 2006-09-17 13:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodte4w9w.fsf@assigned-by-dhcp.cox.net>
---
Junio C Hamano <junkio@cox.net> wrote:
> Matthias Lederhofer <matled@gmx.net> writes:
> The PATHINFO stuff Martin Waitz did mucks with $project somewhat
> later than this part of the patch, possibly bypassing your
> checks. Could you check what's in 'master' to see if it is
> reasonable and if not fix it up please?
This patch replaces the other two warning fixes by Jakub and me. I've
put the whole thing in a sub-routine to keep the indentation level
low.
---
gitweb/gitweb.perl | 34 +++++++++++++++++++++-------------
1 files changed, 21 insertions(+), 13 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 497129a..0fb8638 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -189,9 +189,6 @@ do $GITWEB_CONFIG if -e $GITWEB_CONFIG;
# version of the core git binary
our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
-# path to the current git repository
-our $git_dir;
-
$projects_list ||= $projectroot;
# ======================================================================
@@ -273,30 +270,41 @@ if (defined $searchtext) {
}
# now read PATH_INFO and use it as alternative to parameters
-our $path_info = $ENV{"PATH_INFO"};
-$path_info =~ s|^/||;
-$path_info =~ s|/$||;
-if (validate_input($path_info) && !defined $project) {
+sub evaluate_path_info {
+ return if defined $project;
+ my $path_info = $ENV{"PATH_INFO"};
+ return if !$path_info;
+ $path_info =~ s,(^/|/$),,gs;
+ $path_info = validate_input($path_info);
+ return if !$path_info;
$project = $path_info;
while ($project && !-e "$projectroot/$project/HEAD") {
$project =~ s,/*[^/]*$,,;
}
- if (defined $project) {
- $project = undef unless $project;
+ if (!$project ||
+ ($export_ok && !-e "$projectroot/$project/$export_ok") ||
+ ($strict_export && !project_in_list($project))) {
+ undef $project;
+ return;
}
+ # do not change any parameters if an action is given using the query string
+ return if $action;
if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
# we got "project.git/branch/filename"
$action ||= "blob_plain";
- $hash_base ||= $1;
- $file_name ||= $2;
+ $hash_base ||= validate_input($1);
+ $file_name ||= validate_input($2);
} elsif ($path_info =~ m,^$project/([^/]+)$,) {
# we got "project.git/branch"
$action ||= "shortlog";
- $hash ||= $1;
+ $hash ||= validate_input($1);
}
}
+evaluate_path_info();
-$git_dir = "$projectroot/$project";
+# path to the current git repository
+our $git_dir;
+$git_dir = "$projectroot/$project" if $project;
# dispatch
my %actions = (
--
1.4.2.1.ge767
^ permalink raw reply related
* Re: [PATCH] gitweb: more support for PATH_INFO based URLs
From: Jakub Narebski @ 2006-09-17 13:18 UTC (permalink / raw)
To: git
In-Reply-To: <20060916210832.GV17042@admingilde.org>
Martin Waitz wrote:
> Now three types of path based URLs are supported:
> gitweb.cgi/project.git
> gitweb.cgi/project.git/branch
> gitweb.cgi/project.git/branch/filename
>
> The first one (show project summary) was already supported for a long time
> now. The other two are new: they show the shortlog of a branch or
> the plain file contents of some file contained in the repository.
> + if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
> + # we got "project.git/branch/filename"
> + $action ||= "blob_plain";
> + $hash_base ||= $1;
> + $file_name ||= $2;
> + } elsif ($path_info =~ m,^$project/([^/]+)$,) {
> + # we got "project.git/branch"
> + $action ||= "shortlog";
> + $hash ||= $1;
> + }
I'm sorry, but I realized that I didn't think and check this patch through.
First, this patch spews a bunch of warnings: when PATH_INFO is empty, when
we undefine $project etc. The patches by me and by matled try to address
and remove those warnings, but I'm sure we missed some.
Second, the whole concept of third type of path (path_info) based URL is
flawed: branches can also be hierarchical (for example Junio uses
<initals>/<topic> topic branches, although they are not published).
Therefore it is much harder to distinguish where branchname ends and
filename begins. The patch assumes that branches are flat. So for example
for branch with the name like "gitweb/xmms2" the types 2 and 3 wouldn't
work; and type 1 worked before this patch.
Therefore I rescind my Ack.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: fix warnings from dd70235f5a81e (PATH_INFO)
From: Matthias Lederhofer @ 2006-09-17 12:14 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060916210832.GV17042@admingilde.org>
And removed if in if where one if is enough.
---
Martin Waitz <tali@admingilde.org> wrote:
> + if (defined $project) {
> + $project = undef unless $project;
> + }
This is an if in an if, one if is enough.
> + if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
Warning if $project is undef.
> + } elsif ($path_info =~ m,^$project/([^/]+)$,) {
The same.
> +$git_dir = "$projectroot/$project";
The same.
We really need a gitweb test target.
Something else I noted:
> + while ($project && !-e "$projectroot/$project/HEAD") {
Evaluating $project boolean value leads to problems if a repository is
named "0" (I dunno if there are other strings than "" and "0" which
evaluate to false in perl). There are multiple places where this is
used so I did not change it in this patch (even added one more).
Should this be changed?
---
gitweb/gitweb.perl | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 346c15c..4d39525 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -281,22 +281,20 @@ if (validate_input($path_info) && !defin
while ($project && !-e "$projectroot/$project/HEAD") {
$project =~ s,/*[^/]*$,,;
}
- if (defined $project) {
- $project = undef unless $project;
- }
- if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
+ $project = undef if !$project;
+ if ($project && $path_info =~ m,^$project/([^/]+)/(.+)$,) {
# we got "project.git/branch/filename"
$action ||= "blob_plain";
$hash_base ||= $1;
$file_name ||= $2;
- } elsif ($path_info =~ m,^$project/([^/]+)$,) {
+ } elsif ($project && $path_info =~ m,^$project/([^/]+)$,) {
# we got "project.git/branch"
$action ||= "shortlog";
$hash ||= $1;
}
}
-$git_dir = "$projectroot/$project";
+$git_dir = "$projectroot/$project" if $project;
# dispatch
my %actions = (
--
1.4.2.1.ge767
^ permalink raw reply related
* PATCH] gitweb: Fix warnings when PATH_INFO is empty
From: Jakub Narebski @ 2006-09-17 12:09 UTC (permalink / raw)
To: git
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 44 +++++++++++++++++++++++---------------------
1 files changed, 23 insertions(+), 21 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1549f5f..689528e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -274,29 +274,31 @@ if (defined $searchtext) {
# now read PATH_INFO and use it as alternative to parameters
our $path_info = $ENV{"PATH_INFO"};
-$path_info =~ s|^/||;
-$path_info =~ s|/$||;
-if (validate_input($path_info) && !defined $project) {
- $project = $path_info;
- while ($project && !-e "$projectroot/$project/HEAD") {
- $project =~ s,/*[^/]*$,,;
- }
- if (defined $project) {
- $project = undef unless $project;
- }
- if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
- # we got "project.git/branch/filename"
- $action ||= "blob_plain";
- $hash_base ||= $1;
- $file_name ||= $2;
- } elsif ($path_info =~ m,^$project/([^/]+)$,) {
- # we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= $1;
+if ($path_info) {
+ $path_info =~ s|^/||;
+ $path_info =~ s|/$||;
+ if (validate_input($path_info) && !defined $project) {
+ $project = $path_info;
+ while ($project && !-e "$projectroot/$project/HEAD") {
+ $project =~ s,/*[^/]*$,,;
+ }
+ if (defined $project) {
+ $project = undef unless $project;
+ }
+ if ($path_info =~ m,^$project/([^/]+)/(.+)$,) {
+ # we got "project.git/branch/filename"
+ $action ||= "blob_plain";
+ $hash_base ||= $1;
+ $file_name ||= $2;
+ } elsif ($path_info =~ m,^$project/([^/]+)$,) {
+ # we got "project.git/branch"
+ $action ||= "shortlog";
+ $hash ||= $1;
+ }
}
-}
-$git_dir = "$projectroot/$project";
+ $git_dir = "$projectroot/$project";
+}
# dispatch
my %actions = (
--
1.4.2.1
^ permalink raw reply related
* Re: [PATCH][RFC] Add git-archive-tree
From: Rene Scharfe @ 2006-09-17 11:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Franck Bui-Huu
In-Reply-To: <7v4pvk7jmn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano schrieb:
> Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> I then let the two chew away on the kernel repository. And as
>> kcachegrind impressively shows, all we do with our trees and
>> objects is dwarfed by inflate().
>
> The diff output codepath has a logic that says "if the blob we are
> dealing with has the same object name as the corresponding blob in
> the index, and if the index entry is clean (i.e. it is known that the
> file sitting in the working tree matches the blob), then do not
> inflate() but use data from that file instead".
Nice idea. The tree traverser would need to provide the filenames
relative to the current working directory in addition to the
filenames as they are written to the archive. I guess your para-walk
tree walker could be useful here. I sadly haven't found the time to
look at it, yet, and now it even vanished from the pu branch.
A read is an order of magnitude faster than a deflate of the same data,
at least that's what I guess from comparing the runtimes of git-tar-tree
and tar. _However_, this doesn't account for I/O costs (in my tests the
repo and all checked-out files were cache hot) and for any compression
that would certainly be applied to the resulting archive. So the full
runtime of archive creation wouldn't be that much shorter.
René
^ permalink raw reply
* [PATCH] gitweb fix validating pg (page) parameter
From: Matthias Lederhofer @ 2006-09-17 11:52 UTC (permalink / raw)
To: git
Currently it is possible to give any string ending with a number as
page. -1 for example is quite bad (error log shows probably 100
warnings).
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 497129a..346c15c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -259,7 +259,7 @@ if (defined $hash_parent_base) {
our $page = $cgi->param('pg');
if (defined $page) {
- if ($page =~ m/[^0-9]$/) {
+ if ($page =~ m/[^0-9]/) {
die_error(undef, "Invalid page parameter");
}
}
--
1.4.2.1.ge767
^ permalink raw reply related
* Re: [PATCH 1/2] Add [-s|--hash] option to Linus' show-ref.
From: Christian Couder @ 2006-09-17 11:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eeiskc$l5n$1@sea.gmane.org>
Jakub Narebski wrote:
> Christian Couder wrote:
> > With this option only the sha1 hash of the ref should
> > be printed.
>
> Could you please update manpage as well?
It seems to me that there is no man page for git-show-ref in next right now.
I could add one but I may not describe some part of it correctly.
Christian.
^ permalink raw reply
* [PATCH] git-repack(1): document --window and --depth
From: Jonas Fonseca @ 2006-09-17 11:02 UTC (permalink / raw)
To: git
Copy and pasted from git-pack-objects(1).
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-repack.txt | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 9516227..49f7e0a 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -9,7 +9,7 @@ objects into pack files.
SYNOPSIS
--------
-'git-repack' [-a] [-d] [-f] [-l] [-n] [-q]
+'git-repack' [-a] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]
DESCRIPTION
-----------
@@ -56,6 +56,16 @@ OPTIONS
Do not update the server information with
`git update-server-info`.
+--window=[N], --depth=[N]::
+ These two options affects how the objects contained in the pack are
+ stored using delta compression. The objects are first internally
+ sorted by type, size and optionally names and compared against the
+ other objects within `--window` to see if using delta compression saves
+ space. `--depth` limits the maximum delta depth; making it too deep
+ affects the performance on the unpacker side, because delta data needs
+ to be applied that many times to get to the necessary object.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
--
1.4.2.g39f1
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] git-apply(1): document --unidiff-zero
From: Jonas Fonseca @ 2006-09-17 10:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7v64fm6cuj.fsf@assigned-by-dhcp.cox.net>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-apply.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt
index c76cfff..ee136c1 100644
--- a/Documentation/git-apply.txt
+++ b/Documentation/git-apply.txt
@@ -95,6 +95,16 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
+--unidiff-zero::
+ By default, gitlink:git-apply[1] expects that the patch being
+ applied is a unified diff with at least one line of context.
+ This provides good safety measures, but breaks down when
+ applying a diff generated with --unified=0. To bypass these
+ checks use '--unidiff-zero'.
++
+Note, for the reasons stated above usage of context-free patches are
+discouraged.
+
--apply::
If you use any of the options marked "Turns off
'apply'" above, gitlink:git-apply[1] reads and outputs the
--
1.4.2.g39f1
--
Jonas Fonseca
^ permalink raw reply related
* Re: Notes on supporting Git operations in/on partial Working Directories
From: Junio C Hamano @ 2006-09-17 10:43 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <450AEDBF.9050307@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Junio C Hamano wrote:
> ...
>>
>> Having said that, I do not necessarily agree that highly modular
>> projects would want to put everything in one git repository and
>> track everything as a whole unit.
>
> And yet that's exactly how a lot of developers use CVS. You can argue
> that some other way is better but when they move from CVS they're
> looking for continuity of productivity which often means not radically
> changing how they work. At least in the short term.
(Note. In the next paragraph, I used (for the want of better
wording) the word "unrelated" to mean "indeed related,
but without need to be in sync at whole-tree commit
level, and probably insisting to be in sync at that level
has more disadvantages than advantages". Think of it to
refer to the relationship among more-or-less independent
project subcomponents in my earlier example).
Well, the fact is, it does not make any difference to CVS if you
put unrelated projects in a single "repository", because CVS
does not even have the concept of managing a project as a whole.
Except perhaps that you can give the same tag to individual
files and treat the set of the revs of the files that have that
particular tag forms a revision of a project. And even that is
just a kludge -- if you throw a totally unrelated project into
such a "repository" and give files a tag that happens to be the
same name as the one used in another project, the tool happily
lets you do so and checking out a revision by the tag will pull
files from totally unrelated projects together. We happen to
use the words "repository" and "revision" in git but what they
mean is quite different because we are more whole-tree oriented.
It misses the point to compare CVS and git and say CVS allows
placing unrelated things in the same "repository". CVS does not
even track the whole tree state, so it does not hurt the user
nor the tool even if you did so. With a tool that tracks the
whole tree, you need a bit of thinking and planning.
I do not think, by the way, we are aiming at much different
things. We both know that our current tools do not support
either mode of operation; the direction you are coming from
where everything is under one roof and only parts are accessed
while others are left untouched, or an organization where
loosely-related projects from different repositories are checked
out into a working tree hierarchy. You alluded to "split index"
in another message, and the project organization I suggested to
keep component projects in their own separate repositories would
also have separate indices in component repositories.
I am certainly not opposed to the idea of making operations in
such a tree (built either way) go seamlessly for the users. A
Porcelain that supports such mode of operation needs to be built
or enhanced, because we do not have one.
What I am saying is that I suspect everything-under-one-roof
approach would incur higher damage to the core than multiple
repositories approach. It is my understanding that Cogito has
such a light-weight subproject support that lets you have
separate repositories laid out in a single working tree.
For example, users of such a Porcelain most likely would not
worry about what is stored in .git/index and .git/remotes/
directories of individual repositories that appear in such a
single working tree. The Porcelain would keep track of which
files are locally modified, what components are checked out in
which subdirectory, where their upstream repositories are, and
things like that. It will use .git/index and .git/remotes/ of
component repositories to implement the unified tree, but the
use of the individual .git/ directories is its implementation
detail. It is likely to do its own bookkeeping that is beyond
what the current core offers, but I do not think it needs much
additional core support. If such bookkeeping turns out to be
useful and necessary to have it in the core for whatever reason
(either performance or interoperability across Porcelains), we
could certainly talk about putting that into the core.
I suspect that everything-under-one-roof approach is coming from
an observation that:
- with CVS, projects that share the same cvsroot can be updated
with single 'cvs update' command in a directory close to the
root.
- with git, if you use multiple repositories checked out at
right places in the working tree hierarchy, you need to run
around and say "git checkout" or "git commit" everywhere.
and the latter looks very inconvenient.
But of course the latter is very inconvenient. The current "git
checkout" nor "git commit" are not such subprojects-aware
Porcelain commands. But that does not mean you have to house
everything in the same repository and make partial check-in to
work. You will be enhancing or replacing the same "git checkout"
and "git commit" commands to do so anyway.
^ permalink raw reply
* Re: [PATCH] gitweb: export options
From: Junio C Hamano @ 2006-09-17 10:34 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <20060917090710.GA18153@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> Matthias Lederhofer <matled@gmx.net> writes:
>> Is this replacement for your earlier two patches?
> Yes, it is, they did not apply on the current master. (I fetched the
> new heads, had a short look at the log but forgot to update my working
> heads :) ).
>
>> [PATCH] gitweb: export-ok option
>> [PATCH] gitweb: option 'strict export'
>>
>> What's the difference between this and the previous two?
>
> Now I decided to split it in another way: first remove the
> no-such-directory error and then implement the two new features. The
> patches should be equivalent to those before.
I see.
The PATHINFO stuff Martin Waitz did mucks with $project somewhat
later than this part of the patch, possibly bypassing your
checks. Could you check what's in 'master' to see if it is
reasonable and if not fix it up please?
^ 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