* Re: is gitosis secure?
From: Nix @ 2008-12-13 16:23 UTC (permalink / raw)
To: sverre; +Cc: Thomas Koch, Git Mailing List, dabe
In-Reply-To: <bd6139dc0812090138l5dbaf20bsd1cde00f52bb94e5@mail.gmail.com>
On 9 Dec 2008, Sverre Rabbelier spake thusly:
> On Tue, Dec 9, 2008 at 09:56, Thomas Koch <thomas@koch.ro> wrote:
>> Our admin would prefer to not open SSH at all outside our LAN, but
>> developers would need to have write access also outside the office.
>
> What safer to connect to the LAN than with SSH? What _would_ your
> system admin be happy with using?
telnet. I do not jest, this is our sysadmins' stated reasons for not
opening the git port and for tweaking their (mandatory) HTTP proxy to
block HTTP traffic from git.
(Telnet over some horrible impossibly slow buggy proprietary VPN.
It takes >5min to bring up a single connection.)
Do not underestimate the stupidity and hideboundedness of undertrained
system administrators, for it is vast.
^ permalink raw reply
* Re: is gitosis secure?
From: Sverre Rabbelier @ 2008-12-13 18:07 UTC (permalink / raw)
To: Nix; +Cc: Thomas Koch, Git Mailing List, dabe
In-Reply-To: <87hc58hwmi.fsf@hades.wkstn.nix>
On Sat, Dec 13, 2008 at 17:23, Nix <nix@esperi.org.uk> wrote:
> telnet. I do not jest, this is our sysadmins' stated reasons for not
> opening the git port and for tweaking their (mandatory) HTTP proxy to
> block HTTP traffic from git.
I don't know what to say to this :P.
> (Telnet over some horrible impossibly slow buggy proprietary VPN.
> It takes >5min to bring up a single connection.)
I feel for you man, try and get that guy fired and have them hire some
_real_ sysadmins!
> Do not underestimate the stupidity and hideboundedness of undertrained
> system administrators, for it is vast.
This is beyond doubt.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Let git remote accept up as alias to update
From: Alexey Zaytsev @ 2008-12-13 18:18 UTC (permalink / raw)
To: git
Signed-off-by: Alexey Zaytsev <alexey.zaytsev@gmail.com>
---
Don't know why, but I keep typing remote up instead of
remote update. As update is probably by far the most
used remote action, can we please have this alias?
builtin-remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-remote.c b/builtin-remote.c
index abc8dd8..8f5cd6d 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -893,7 +893,7 @@ int cmd_remote(int argc, const char **argv, const char *prefix)
result = show(argc, argv);
else if (!strcmp(argv[0], "prune"))
result = prune(argc, argv);
- else if (!strcmp(argv[0], "update"))
+ else if (!strcmp(argv[0], "update") || !strcmp(argv[0], "up"))
result = update(argc, argv);
else {
error("Unknown subcommand: %s", argv[0]);
^ permalink raw reply related
* Re: Optimizing cloning of a high object count repository
From: Resul Cetin @ 2008-12-13 18:20 UTC (permalink / raw)
To: git; +Cc: Jean-Luc Herren, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <4943E657.9040204@gmx.ch>
On Saturday 13 December 2008 17:44:07 you wrote:
> Resul Cetin wrote:
> > That would be a workaround but it doesn't explain why git.kernel.org
> > deliveres torvalds repository without any notable counting and
> > compressing time.
>
> If I remember right, git.kernel.org is a quite beefy machine. But
> then again it has a lot more traffic too. It might be interesting
> to know what machine you're on, compared to git.kernel.org.
I dont know what type of machine git.overlay.g.o is but my athlon64 3500+ with
4GB ram has exactly the same problem without any other load. I made a clone
over http and did no other changes to the repository until now.
http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/ is the http clone
url.
I will try some stuff to reduce the time spend before sending anything..... If
anyone has some ideas how to do that....
Regards,
Resul
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Nicolas Pitre @ 2008-12-13 18:56 UTC (permalink / raw)
To: Resul Cetin; +Cc: git, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <200812131714.05472.Resul-Cetin@gmx.net>
On Sat, 13 Dec 2008, Resul Cetin wrote:
> On Saturday 13 December 2008 16:46:50 you wrote:
> [...]
> > > The size of the linux repository seems to be smaller but in the same
> > > range object count and repository size but clones are much much faster.
> > > Is there any way to optimize the server operations like counting and
> > > compressing of objects to get the same speed as we get from
> > > git.kernel.org (which does it in nearly no time and the only limiting
> > > factor seems to be my bandwith)?
> > > The only other information I have is that Robin H. Johnson made a single
> > > ~910MiB pack for the whole repository.
> >
> > Make yearly packed repository snapshots and publish them via http.
> > People can wget the latest snapshot, then pull updates later.
> That would be a workaround but it doesn't explain why git.kernel.org deliveres
> torvalds repository without any notable counting and compressing time. Maybe
> it has something todo with the config I found inside the repository:
> http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/config
> It says that it isnt a bare repository.
That's not relevant.
The counting time is a bit unfortunate (although I have plans to speed
that up, if only I can find the time).
You should be able to skip the compression time entirely though, if you
do repack the repository first. And you want it to be as tightly packed
as possible for public access. I'm currently cloning it and the
counting phase is not _that_ bad compared to the compression phase. Try
something like 'git repack -a -f -d --window=200' and let it run
overnight if necessary. You need to do this only once, and preferably
on a machine with lots of RAM, and preferably on a 64-bit machine. Once
this is done then things should go much more smoothly afterwards.
Nicolas
^ permalink raw reply
* [PATCH] bash completion: remove deprecated --prune from git-gc
From: Markus Heidelberg @ 2008-12-13 19:08 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..9e0c48b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -835,7 +835,7 @@ _git_gc ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--*)
- __gitcomp "--prune --aggressive"
+ __gitcomp "--aggressive"
return
;;
esac
--
1.6.1.rc1.54.gd1643
^ permalink raw reply related
* [PATCH] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Matt McCutchen @ 2008-12-13 19:10 UTC (permalink / raw)
To: git
My Web site uses pathinfo mode and some rewrite magic to show the gitweb
interface at the URL of the real repository directory (which users also
pull from). In this case, it's desirable to end generated links to the
project in a trailing slash so the Web server doesn't have to redirect
the client to add the slash. This patch adds a second element to the
"pathinfo" feature configuration to control the trailing slash.
---
What do you think of this? I've been using it on my Web site for a
while now.
Matt
gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..86511cf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -270,6 +270,11 @@ our %feature = (
# $feature{'pathinfo'}{'default'} = [1];
# Project specific override is not supported.
+ # If you want a trailing slash on the project path (because, for
+ # example, you have a real directory at that URL and are using
+ # some rewrite magic to invoke gitweb), then set:
+ # $feature{'pathinfo'}{'default'} = [1, 1];
+
# Note that you will need to change the default location of CSS,
# favicon, logo and possibly other files to an absolute URL. Also,
# if gitweb.cgi serves as your indexfile, you will need to force
@@ -829,8 +834,8 @@ sub href (%) {
}
}
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
@@ -845,7 +850,12 @@ sub href (%) {
$href =~ s,/$,,;
# Then add the project name, if present
- $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
+ my $proj_href = undef;
+ if (defined $params{'project'}) {
+ $href .= "/".esc_url($params{'project'});
+ # Save for trailing-slash check below.
+ $proj_href = $href;
+ }
delete $params{'project'};
# since we destructively absorb parameters, we keep this
@@ -903,6 +913,10 @@ sub href (%) {
$href .= $known_snapshot_formats{$fmt}{'suffix'};
delete $params{'snapshot_format'};
}
+
+ # If requested in the configuration, add a trailing slash to a URL that
+ # has nothing appended after the project path.
+ $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
}
# now encode the parameters explicitly
@@ -2987,13 +3001,15 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
$action .= "/".esc_url($project);
+ # Add a trailing slash if requested in the configuration.
+ $action .= '/' if ($use_pathinfo[1]);
}
print $cgi->startform(-method => "get", -action => $action) .
"<div class=\"search\">\n" .
- (!$use_pathinfo &&
+ (!$use_pathinfo[0] &&
$cgi->input({-name=>"p", -value=>$project, -type=>"hidden"}) . "\n") .
$cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . "\n" .
$cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) . "\n" .
--
1.6.1.rc2.24.gf17b3c.dirty
^ permalink raw reply related
* Re: [PATCH] autodetect number of CPUs by default when using threads
From: Nicolas Pitre @ 2008-12-13 19:27 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20081213133238.GA6718@sigill.intra.peff.net>
On Sat, 13 Dec 2008, Jeff King wrote:
> On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
>
> > ... and display the actual number of threads used when locally
> > repacking. A remote server still won't tell you how many threads it
> > uses during a fetch though.
>
> Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
> my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
> Sample verbose output is below.
Hmmm... Interesting.
Nicolas
^ permalink raw reply
* Re: [patch] Fix a corner case in git update-index --index-info
From: Junio C Hamano @ 2008-12-13 19:29 UTC (permalink / raw)
To: Thomas Jarosch; +Cc: git
In-Reply-To: <200812131403.08740.thomas.jarosch@intra2net.com>
Thomas Jarosch <thomas.jarosch@intra2net.com> writes:
> Fix a corner case in git update-index --index-info:
> If there are no input lines, it won't create an empty index.
>
> Here's a short test for this:
> echo -n "" |GIT_INDEX_FILE=index.new git update-index --index-info
> -> The index "index.new" won't get created
>
> It failed for me while I was using
> git filter-branch as described in the man page:
>
> git filter-branch --index-filter \
> ´git ls-files -s | sed "s-\t-&newsubdir/-" |
> GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> git update-index --index-info &&
> mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE´ HEAD
>
> The conversion aborted because the first commit was empty.
> (created by cvs2svn)
If you are doing a filter-branch and the commits near the beginning of the
history did not have any path you are interested in, I do not think you
would want to even create corresponding commits for them that record an
empty tree to begin with, so I do not necessarily agree with the above
command line. The mv would fail due to absense of index.new file, and you
can take it as a sign that you can skip that commit.
Outside the context of your command line above, I am slightly more
sympathetic than neutral to the argument that "update-index --index-info"
(and "update-index --stdin", which I suspect would have the same issue,
but I did not check) should create an output file if one did not exist.
You should note however that such a change would rob from you a way to
detect that you did not feed anything to the command by checking the lack
of the output. Such a change would break people's existing scripts that
relied on the existing behaviour; one example is that the above "The mv
would fail...and you can" would be made impossible.
> @@ -308,6 +309,8 @@ static void read_index_info(int line_termination)
> unsigned long ul;
> int stage;
>
> + found_something = 1;
> +
> /* This reads lines formatted in one of three formats:
> *
> * (1) mode SP sha1 TAB path
> @@ -383,6 +386,11 @@ static void read_index_info(int line_termination)
> bad_line:
> die("malformed index info %s", buf.buf);
> }
> +
> + /* Force creation of empty index - needed by git filter-branch */
As I already mentioned, I do not agree with this "needed by" at all.
> + if (!found_something)
> + active_cache_changed = 1;
> +
> strbuf_release(&buf);
> strbuf_release(&uq);
> }
I think this implementation is conceptually wrong, even if we assume it is
the right thing to always create a new file. The --index-info mode may
well be fed with the same information as it already records, in which case
active_cache_changed shouldn't be toggled, and if it is fed something
different from what is recorded, active_cache_changed should be marked as
changed, and that decision should be left to the add_cache_entry() that is
called from add_cacheinfo(). What you did is to make it _always_ write
the new index out, even if we started with an existing index, and there
was no change, or even if we started with missing index, and there was no
input. You only wanted the latter but you did both.
If that is what you want to do, you can get rid of found_something logic
altogether and flip active_cache_changed unconditionally to do the same
thing, but it feels wrong to write the index out when nothing changed.
Since I said I am slightly more sympathetic than neutral, here is a patch
that forces creation of an empty index file without making it write out
the same thing if the index already existed.
But again, this would break people who have been relying on the existing
behaviour that no resulting file, when GIT_INDEX_FILE points at a
nonexistent file, signals no operation.
I think it is a bad idea to do this in -rc period, even if we were to
change the semantics.
builtin-update-index.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git c/builtin-update-index.c w/builtin-update-index.c
index 65d5775..9abc0b2 100644
--- c/builtin-update-index.c
+++ w/builtin-update-index.c
@@ -566,6 +566,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
char set_executable_bit = 0;
unsigned int refresh_flags = 0;
int lock_error = 0;
+ int was_unborn;
struct lock_file *lock_file;
git_config(git_default_config, NULL);
@@ -580,6 +581,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
entries = read_cache();
if (entries < 0)
die("cache corrupted");
+ was_unborn = is_cache_unborn();
for (i = 1 ; i < argc; i++) {
const char *path = argv[i];
@@ -677,7 +679,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
die("--index-info must be at the end");
allow_add = allow_replace = allow_remove = 1;
read_index_info(line_termination);
- break;
+ goto finish;
}
if (!strcmp(path, "--unresolve")) {
has_errors = do_unresolve(argc - i, argv + i,
@@ -738,7 +740,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
}
finish:
- if (active_cache_changed) {
+ if (active_cache_changed || was_unborn) {
if (newfd < 0) {
if (refresh_flags & REFRESH_QUIET)
exit(128);
^ permalink raw reply related
* Adding Exit status documentation to all git commands starting with git status
From: nadim khemir @ 2008-12-13 19:36 UTC (permalink / raw)
To: git list
I was asking on the irc channel about how to know if I need to commit. I
promptely got answered but during the discussion, the few of us still awake
in the middle of the night (for me at least), agreed that it would be good to
have a EXIT STATUS in all the commands documentation starting with
the 'status' command.
The current documentation of 'git status' does cover exit status and looks
like:
<original>
...
shows what would be committed if the same options are given to
'git-commit'.
If there is no path that is different between the index file and
the current HEAD commit (i.e., there is nothing to commit by running
`git commit`), the command exits with non-zero status.
OUTPUT
------
</original>
There are different styles to add exit status, give me your input on why and
why not using one or the other. I list 3 solutions and what I think about
them.
<solution 1, least change, easier to recognize although all the negations and
the explaination being about when the command ~fails~ makes newbies head spin
for a few seconds>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
The command exits with non-zero status if there is no path that is
different between the index file and the current HEAD commit (i.e.,
there is nothing to commit by running `git commit`).
OUTPUT
------
</solution 1>
<solution 2, both zero and non zero status>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
Zero status: There is a different between the index file and HEAD.
Non-zero status: There is nothing to commit by running `git commit`.
OUTPUT
------
</solution 2>
<solution 3, Only zero status, non zero is easilly deducted. Clearest IMO>
...
shows what would be committed if the same options are given to
'git-commit'.
EXIT STATUS
-----------
Zero status: There is a different between the index and HEAD; running
`git commit` would create a new commit.
OUTPUT
------
</solution 3>
A few things could be better explained:
- The command is to be run with '-a' as option.
- The fact that non add'ed files are not taken into account is not
completely obvious. The first paragraph of the DESCRIPTION explains it but it
is not the clearest explaination ever (maybe because it's not easy to explain
and man pages are references not user manuals)
Cheers, Nadim.
^ permalink raw reply
* Re: Adding Exit status documentation to all git commands starting with git status
From: Junio C Hamano @ 2008-12-13 20:04 UTC (permalink / raw)
To: nadim khemir; +Cc: git list
In-Reply-To: <200812132036.39318.nadim@khemir.net>
nadim khemir <nadim@khemir.net> writes:
> There are different styles to add exit status, give me your input on why and
> why not using one or the other. I list 3 solutions and what I think about
> them.
No matter what you do, I think EXIT STATUS section should consistently
come near the end of the document, immediately before SEE ALSO, which is
where people who know how manual pages are written expect to find it.
> EXIT STATUS
> -----------
> The command exits with non-zero status if there is no path that is
> different between the index file and the current HEAD commit (i.e.,
> there is nothing to commit by running `git commit`).
Prose is much easier to read as long as it is brief enough, than two-item
enumeration:
> EXIT STATUS
> -----------
> Zero status: There is a different between the index file and HEAD.
> Non-zero status: There is nothing to commit by running `git commit`.
whose use of "Zero status" makes it look doubly funny (traditionally
manual pages do not seem to spell out exit status 0 as "zero", but
"non-zero" is Ok).
Avoid talking about only one side of the condition if you can without
being too verbose.
The command exits with status 0 if there is something to commit by
running `git commit` with corresponding arguments, and non-zero
otherwise.
^ permalink raw reply
* [PATCH] pack-objects: don't use too many threads with few objects
From: Nicolas Pitre @ 2008-12-13 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <20081213133238.GA6718@sigill.intra.peff.net>
If there are few objects to deltify, they might be split amongst threads
so that there is simply no other objects left to delta against within
the same thread. Let's use the same 2*window treshold as used for the
final load balancing to allow extra threads to be created.
This fixes the benign t5300 test failure.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Sat, 13 Dec 2008, Jeff King wrote:
> On Thu, Dec 11, 2008 at 03:36:47PM -0500, Nicolas Pitre wrote:
>
> > ... and display the actual number of threads used when locally
> > repacking. A remote server still won't tell you how many threads it
> > uses during a fetch though.
>
> Hrm. I have no idea how, but this patch reliably causes t5300 to fail on
> my FreeBSD test box ("next" is broken, bisection pointed to 43cc2b42).
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 619e597..e851534 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1620,6 +1620,10 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
for (i = 0; i < delta_search_threads; i++) {
unsigned sub_size = list_size / (delta_search_threads - i);
+ /* don't use too small segments or no deltas will be found */
+ if (sub_size < 2*window && i+1 < delta_search_threads)
+ sub_size = 0;
+
p[i].window = window;
p[i].depth = depth;
p[i].processed = processed;
^ permalink raw reply related
* [PATCH v3] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-13 20:47 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7viqprzsvs.fsf@gitster.siamese.dyndns.org>
I want directories of my working tree to be linked to from various
paths on my filesystem where third-party components expect them, both
in development and production environments. A build system's install
step could solve this, but we develop scripts and web pages that don't
need to be built. Git's submodule system could solve this, but we
tend to develop, branch, and test those directories all in unison, so
one big repository feels more natural. We prefer to edit and commit
on the symlinked paths, not the canonical ones, and in that setting,
"git pull" fails to find the top-level directory of the working tree
and the .git directory in it.
"git pull" fails because POSIX shells have a notion of current working
directory that is different from getcwd(). The shell stores this path
in PWD. As a result, "cd ../" in a shell script can be interpretted
differently in a shell than chdir("../") in a C program. The shell
interprets "../" by essentially stripping the last textual path
component from PWD, whereas C chdir() follows the ".." link in the
current directory on the filesystem. When PWD is a symlink, these are
different destinations. As a result, Git's C commands find the
correct top-level working tree, and shell scripts do not.
Changes:
* When interpretting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus contrasting scenarios
that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
Hopefully the new commit message adequately describes the problem and
motivation for solving it without getting too long-winded or bogged down
in personal details.
I also removed the "pwd -P" from the unit test. I originally worried
that it was little like testing an algorithm by running it twice and
checking the results against eachother. But I guess having the unit
tests run on unusual platforms is more important.
The pull-symlink test cases should now fail independently. I also
moved the setup out of the test_expect_success block for symetry and
since I see that other tests don't check for setup failure. There's
no "set -e" or anything to catch a setup failure other than the
eventual test cases push/pull not working. So is it good form in this
situation to not check the setup steps for success? Or would it make
sense to put them in their own 'setup' test case? Or would it be better
to just "exit 1" if they fail?
> > +ln -s repo symrepo
> > +test_cd_to_toplevel symrepo 'at symbolic root'
> > +
> > +ln -s repo/sub/dir subdir-link
> > +test_cd_to_toplevel subdir-link 'at symbolic subdir'
> > +
> > +cd repo
> > +ln -s sub/dir internal-link
> > +test_cd_to_toplevel internal-link 'at internal symbolic subdir'
>
> To be very honest, although it is good that you made them work, I am still
> not getting why the latter two scenarios are worth supporting. The first
> one I am Ok with, though.
The middle scenario is the one I want most. I hope the first
paragraph of the commit message sheds more light on the reason.
The third is really just there for completeness (although there are
other cases I didn't include...). Since Git supports operation below
the top-level, and it supports symlinks, it seems useful to test the
cooperation of those features. I wouldn't miss it much if you thought
it was not interesting enough.
> > +
> > +# Prove that the remote end really is a repo, and other commands
> > +# work fine in this context.
> > +#
> > +test_debug "
> > + test_expect_success 'pushing from symlinked subdir' '
> > +
> > + git push
> > + '
> > +"
>
> Why should this be hidden inside test_debug?
I'm not particularly trying to test "git push" or "git pull" in
general here. That's also why the other "git pull" was in a
test_debug. I thought it was really only useful to someone trying to
understand the contents of the test file. There are other files that
cover push and pull. Do you think these test cases should run all the
time here?
git-sh-setup.sh | 23 +++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++++
t/t5521-pull-symlink.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 131 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..05854b4
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(pwd -P)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(/bin/pwd)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..8869262
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+
+mkdir subdir
+touch subdir/bar
+git add subdir/bar
+git commit -m empty
+git clone . clone-repo
+ln -s clone-repo/subdir/ subdir-link
+
+
+# Demonstrate that things work if we just avoid the symlink
+#
+test_debug "
+ test_expect_success 'pulling from real subdir' '
+ (
+ cd clone-repo/subdir/ &&
+ git pull
+ )
+ '
+"
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. A POSIX shell's "cd" works a little differently
+# than chdir() in C; "cd -P" is much closer to chdir().
+#
+test_expect_success 'pulling from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ git pull
+ )
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context. It's just that "git pull" breaks.
+#
+test_debug "
+ test_expect_success 'pushing from symlinked subdir' '
+ (
+ cd subdir-link/ &&
+ git push
+ )
+ '
+"
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Matt McCutchen @ 2008-12-13 21:11 UTC (permalink / raw)
To: git
In-Reply-To: <1229195421.3943.8.camel@mattlaptop2.local>
My Web site uses pathinfo mode and some rewrite magic to show the gitweb
interface at the URL of the real repository directory (which users also
pull from). In this case, it's desirable to end generated links to the
project in a trailing slash so the Web server doesn't have to redirect
the client to add the slash. This patch adds a second element to the
"pathinfo" feature configuration to control the trailing slash.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
Resending with a sign-off.
gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
1 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 6eb370d..86511cf 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -270,6 +270,11 @@ our %feature = (
# $feature{'pathinfo'}{'default'} = [1];
# Project specific override is not supported.
+ # If you want a trailing slash on the project path (because, for
+ # example, you have a real directory at that URL and are using
+ # some rewrite magic to invoke gitweb), then set:
+ # $feature{'pathinfo'}{'default'} = [1, 1];
+
# Note that you will need to change the default location of CSS,
# favicon, logo and possibly other files to an absolute URL. Also,
# if gitweb.cgi serves as your indexfile, you will need to force
@@ -829,8 +834,8 @@ sub href (%) {
}
}
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
@@ -845,7 +850,12 @@ sub href (%) {
$href =~ s,/$,,;
# Then add the project name, if present
- $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
+ my $proj_href = undef;
+ if (defined $params{'project'}) {
+ $href .= "/".esc_url($params{'project'});
+ # Save for trailing-slash check below.
+ $proj_href = $href;
+ }
delete $params{'project'};
# since we destructively absorb parameters, we keep this
@@ -903,6 +913,10 @@ sub href (%) {
$href .= $known_snapshot_formats{$fmt}{'suffix'};
delete $params{'snapshot_format'};
}
+
+ # If requested in the configuration, add a trailing slash to a URL that
+ # has nothing appended after the project path.
+ $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
}
# now encode the parameters explicitly
@@ -2987,13 +3001,15 @@ EOF
$search_hash = "HEAD";
}
my $action = $my_uri;
- my $use_pathinfo = gitweb_check_feature('pathinfo');
- if ($use_pathinfo) {
+ my @use_pathinfo = gitweb_get_feature('pathinfo');
+ if ($use_pathinfo[0]) {
$action .= "/".esc_url($project);
+ # Add a trailing slash if requested in the configuration.
+ $action .= '/' if ($use_pathinfo[1]);
}
print $cgi->startform(-method => "get", -action => $action) .
"<div class=\"search\">\n" .
- (!$use_pathinfo &&
+ (!$use_pathinfo[0] &&
$cgi->input({-name=>"p", -value=>$project, -type=>"hidden"}) . "\n") .
$cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . "\n" .
$cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) . "\n" .
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* [PATCH 2/2] gitweb: support hiding projects from user-visible lists
From: Matt McCutchen @ 2008-12-13 21:16 UTC (permalink / raw)
To: git
In-Reply-To: <4ba6b6c3fc183002407f322663d7ab53c1c28a91.1229202740.git.matt@mattmccutchen.net>
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
My Web site has a single gitweb installation in which some of the
repositories are protected by a basic authentication login. By virtue
of my aforementioned setup with gitweb and pulling at the same URL, the
login applies uniformly to both. I had to include these repositories in
the projects_list because I use strict_export, but I want to hide them
when the user views the project list. This patch implements that
feature, and the previous one fixes a bug I noticed along the way.
Matt
gitweb/gitweb.perl | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 5357bcc..085cc60 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1144,7 +1144,7 @@ sub untabify {
sub project_in_list {
my $project = shift;
- # Tell git_get_projects_list to include forks.
+ # Tell git_get_projects_list to include forks and hidden repositories.
my @list = git_get_projects_list(undef, 1);
return @list && scalar(grep { $_->{'path'} eq $project } @list);
}
@@ -2174,15 +2174,18 @@ sub git_get_projects_list {
# 'git%2Fgit.git Linus+Torvalds'
# 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
# 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
+ #
+ # 1 in the third field hides the project from user-visible lists, e.g.:
+ # 'linux%2Fembargoed-security-fixes.git John+Doe 1'
my %paths;
open my ($fd), $projects_list or return;
PROJECT:
while (my $line = <$fd>) {
chomp $line;
- my ($path, $owner) = split ' ', $line;
+ my ($path, $owner, $hidden) = split ' ', $line;
$path = unescape($path);
$owner = unescape($owner);
- if (!defined $path) {
+ if (!defined $path || ($hidden && !$for_strict_export)) {
next;
}
if ($filter ne '') {
@@ -2227,6 +2230,8 @@ sub git_get_projects_list {
return @list;
}
+# This is used to look up the owner of a project the user is already allowed to
+# see, so we shouldn't omit hidden repositories.
our $gitweb_project_owner = undef;
sub git_get_project_list_from_file {
@@ -2241,7 +2246,7 @@ sub git_get_project_list_from_file {
open (my $fd , $projects_list);
while (my $line = <$fd>) {
chomp $line;
- my ($pr, $ow) = split ' ', $line;
+ my ($pr, $ow, $hidden) = split ' ', $line;
$pr = unescape($pr);
$ow = unescape($ow);
$gitweb_project_owner->{$pr} = to_utf8($ow);
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* [PATCH 1/2] gitweb: allow access to forks with strict_export
From: Matt McCutchen @ 2008-12-13 21:16 UTC (permalink / raw)
To: git
git_get_projects_list excludes forks in order to unclutter the main
project list, but this caused the strict_export check, which also relies
on git_get_project_list, to incorrectly fail for forks. This patch adds
an argument so git_get_projects_list knows when it is being called for a
strict_export check (as opposed to a user-visible project list) and
doesn't exclude the forks.
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 86511cf..5357bcc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1144,7 +1144,8 @@ sub untabify {
sub project_in_list {
my $project = shift;
- my @list = git_get_projects_list();
+ # Tell git_get_projects_list to include forks.
+ my @list = git_get_projects_list(undef, 1);
return @list && scalar(grep { $_->{'path'} eq $project } @list);
}
@@ -2128,13 +2129,13 @@ sub git_get_project_url_list {
}
sub git_get_projects_list {
- my ($filter) = @_;
+ my ($filter, $for_strict_export) = @_;
my @list;
$filter ||= '';
$filter =~ s/\.git$//;
- my $check_forks = gitweb_check_feature('forks');
+ my $check_forks = !$for_strict_export && gitweb_check_feature('forks');
if (-d $projects_list) {
# search in directory
--
1.6.1.rc2.27.gc7114
^ permalink raw reply related
* Re: [JGIT PATCH 2/2] Add getPatchText functions to obtain the plain-text version of a patch
From: Robin Rosenberg @ 2008-12-13 21:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <200812131202.07717.robin.rosenberg.lists@dewire.com>
lördag 13 december 2008 12:02:07 skrev Robin Rosenberg:
> lördag 13 december 2008 03:42:26 skrev Shawn O. Pearce:
> > The conversion from byte[] to String is performed one line at a time,
> > in case the patch is a character encoding conversion patch for the
> > file. For simplicity we currently assume UTF-8 still as the default
> > encoding for any content, but eventually we should support using the
> > .gitattributes encoding property when performing this conversion.
>
> For usefulness we must be able to pass the encoding from outside,
> e.g. the encoding Eclipse uses, which often is not UTF-8-
It's even worse. You should probably do the encoding guess on the whole
patch, or per file and not per line so make success possible at all. Reading
and writing as ISO-8859-1 will always work as that is just padding every
byte with NUL on reading and dropping it on writing. I.e. if your convert
to char at all...
-- robin
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Jakub Narebski @ 2008-12-13 21:47 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Giuseppe Bilotta
In-Reply-To: <1229202689.31181.1.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
> My Web site uses pathinfo mode and some rewrite magic to show the gitweb
> interface at the URL of the real repository directory (which users also
> pull from). In this case, it's desirable to end generated links to the
> project in a trailing slash so the Web server doesn't have to redirect
> the client to add the slash. This patch adds a second element to the
> "pathinfo" feature configuration to control the trailing slash.
>
> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Did you check that it does not confuse gitweb if filename parameter is
passed using pathinfo? Gitweb used to rely on final '/' to
distinguish directory pathnames from ordinary pathnames, but I think
currently thanks to the fact that gitweb now embeds action in pathinfo
URL, and does not need to guess type, it is not an issue.
Or only project URLs (i.e. only with project parameter, i.e. only
"http://git.example.com/project.git/" but not other path_info links)
have trailing slash added?
Errr... I see that it adds trailing slash only for project-only
path_info links, but the commit message was not entirely clear for me.
(CC-ed author of path_info enhancements, Giuseppe Bilotta)
> ---
> Resending with a sign-off.
Thanks.
> gitweb/gitweb.perl | 28 ++++++++++++++++++++++------
> 1 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 6eb370d..86511cf 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -270,6 +270,11 @@ our %feature = (
> # $feature{'pathinfo'}{'default'} = [1];
> # Project specific override is not supported.
>
> + # If you want a trailing slash on the project path (because, for
> + # example, you have a real directory at that URL and are using
> + # some rewrite magic to invoke gitweb), then set:
> + # $feature{'pathinfo'}{'default'} = [1, 1];
> +
Are any disadvantages to having it always enabled?
BTW. encoding data in position in array feels a bit hacky to me, but
I guess that is the limitation of current %feature design, with
'default' having to be array (reference).
> # Note that you will need to change the default location of CSS,
> # favicon, logo and possibly other files to an absolute URL. Also,
> # if gitweb.cgi serves as your indexfile, you will need to force
> @@ -829,8 +834,8 @@ sub href (%) {
> }
> }
>
> - my $use_pathinfo = gitweb_check_feature('pathinfo');
> - if ($use_pathinfo) {
> + my @use_pathinfo = gitweb_get_feature('pathinfo');
Why not name those variables for better readability?
+ my ($use_pathinfo, $trailing_slash) = gitweb_get_feature('pathinfo');
> + if ($use_pathinfo[0]) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> @@ -845,7 +850,12 @@ sub href (%) {
> $href =~ s,/$,,;
>
> # Then add the project name, if present
> - $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> + my $proj_href = undef;
> + if (defined $params{'project'}) {
> + $href .= "/".esc_url($params{'project'});
> + # Save for trailing-slash check below.
> + $proj_href = $href;
> + }
> delete $params{'project'};
>
> # since we destructively absorb parameters, we keep this
> @@ -903,6 +913,10 @@ sub href (%) {
> $href .= $known_snapshot_formats{$fmt}{'suffix'};
> delete $params{'snapshot_format'};
> }
> +
> + # If requested in the configuration, add a trailing slash to a URL that
> + # has nothing appended after the project path.
> + $href .= '/' if ($use_pathinfo[1] && defined $proj_href && $href eq $proj_href);
> }
The check _feels_ inefficient. I think (but feel free to disagree) that
it would be better to use something like $project_pathinfo, set it
when adding project as pathinfo, and unset if we add anything else as
pathinfo.
>
> # now encode the parameters explicitly
> @@ -2987,13 +3001,15 @@ EOF
> $search_hash = "HEAD";
> }
> my $action = $my_uri;
> - my $use_pathinfo = gitweb_check_feature('pathinfo');
> - if ($use_pathinfo) {
> + my @use_pathinfo = gitweb_get_feature('pathinfo');
Same comment as above: better named variable instead of relying on
position in array.
> + if ($use_pathinfo[0]) {
> $action .= "/".esc_url($project);
> + # Add a trailing slash if requested in the configuration.
> + $action .= '/' if ($use_pathinfo[1]);
Hmmm... let me check something... you rely on the fact that $project
doesn't end with slash, while I think (but please check it) that it
can end with slash if it is provided by CGI query.
> }
> print $cgi->startform(-method => "get", -action => $action) .
> "<div class=\"search\">\n" .
> - (!$use_pathinfo &&
> + (!$use_pathinfo[0] &&
> $cgi->input({-name=>"p", -value=>$project, -type=>"hidden"}) . "\n") .
> $cgi->input({-name=>"a", -value=>"search", -type=>"hidden"}) . "\n" .
> $cgi->input({-name=>"h", -value=>$search_hash, -type=>"hidden"}) . "\n" .
> --
> 1.6.1.rc2.27.gc7114
>
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Optimizing cloning of a high object count repository
From: Nicolas Pitre @ 2008-12-13 21:50 UTC (permalink / raw)
To: Resul Cetin; +Cc: git, Nguyen Thai Ngoc Duy, gentoo-scm
In-Reply-To: <alpine.LFD.2.00.0812131347130.30035@xanadu.home>
On Sat, 13 Dec 2008, Nicolas Pitre wrote:
> On Sat, 13 Dec 2008, Resul Cetin wrote:
>
> > On Saturday 13 December 2008 16:46:50 you wrote:
> > [...]
> > > > The size of the linux repository seems to be smaller but in the same
> > > > range object count and repository size but clones are much much faster.
> > > > Is there any way to optimize the server operations like counting and
> > > > compressing of objects to get the same speed as we get from
> > > > git.kernel.org (which does it in nearly no time and the only limiting
> > > > factor seems to be my bandwith)?
> > > > The only other information I have is that Robin H. Johnson made a single
> > > > ~910MiB pack for the whole repository.
> > >
> > > Make yearly packed repository snapshots and publish them via http.
> > > People can wget the latest snapshot, then pull updates later.
> > That would be a workaround but it doesn't explain why git.kernel.org deliveres
> > torvalds repository without any notable counting and compressing time. Maybe
> > it has something todo with the config I found inside the repository:
> > http://git.overlays.gentoo.org/gitroot/exp/gentoo-x86.git/config
> > It says that it isnt a bare repository.
>
> That's not relevant.
>
> The counting time is a bit unfortunate (although I have plans to speed
> that up, if only I can find the time).
>
> You should be able to skip the compression time entirely though, if you
> do repack the repository first. And you want it to be as tightly packed
> as possible for public access. I'm currently cloning it and the
> counting phase is not _that_ bad compared to the compression phase. Try
> something like 'git repack -a -f -d --window=200' and let it run
> overnight if necessary. You need to do this only once, and preferably
> on a machine with lots of RAM, and preferably on a 64-bit machine. Once
> this is done then things should go much more smoothly afterwards.
FYI, I repacked that repository after cloning it, and that operation
required around 2.5G of resident memory. Given the address space
fragmentation, it is possible that a full repack cannot be performed on
a 32-bit machine.
I did 'git repack -a -f -d --window=500 --depth=100'. This took less
than an hour on a quad core machine. The resulting pack is 695MB in
size. That's the amount of data that would be transfered during a
clone of this repository, and nothing would have to be compressed during
the clone as everything is already fully compressed.
Nicolas
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: allow access to forks with strict_export
From: Jakub Narebski @ 2008-12-13 21:53 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Petr Baudis
In-Reply-To: <1229203014.31181.7.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
CC-ed Petr Baudis, author of forks support in gitweb.
> git_get_projects_list excludes forks in order to unclutter the main
> project list, but this caused the strict_export check, which also relies
> on git_get_project_list, to incorrectly fail for forks. This patch adds
> an argument so git_get_projects_list knows when it is being called for a
> strict_export check (as opposed to a user-visible project list) and
> doesn't exclude the forks.
>
> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Looks good for me.
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 86511cf..5357bcc 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1144,7 +1144,8 @@ sub untabify {
>
> sub project_in_list {
> my $project = shift;
> - my @list = git_get_projects_list();
> + # Tell git_get_projects_list to include forks.
> + my @list = git_get_projects_list(undef, 1);
> return @list && scalar(grep { $_->{'path'} eq $project } @list);
> }
>
> @@ -2128,13 +2129,13 @@ sub git_get_project_url_list {
> }
>
> sub git_get_projects_list {
> - my ($filter) = @_;
> + my ($filter, $for_strict_export) = @_;
> my @list;
>
> $filter ||= '';
> $filter =~ s/\.git$//;
>
> - my $check_forks = gitweb_check_feature('forks');
> + my $check_forks = !$for_strict_export && gitweb_check_feature('forks');
>
> if (-d $projects_list) {
> # search in directory
> --
> 1.6.1.rc2.27.gc7114
>
>
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: support hiding projects from user-visible lists
From: Jakub Narebski @ 2008-12-13 22:02 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1229203007.31181.6.camel@mattlaptop2.local>
Matt McCutchen <matt@mattmccutchen.net> writes:
Commit message, please?
> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
> ---
>
> My Web site has a single gitweb installation in which some of the
> repositories are protected by a basic authentication login. By virtue
> of my aforementioned setup with gitweb and pulling at the same URL, the
> login applies uniformly to both. I had to include these repositories in
> the projects_list because I use strict_export, but I want to hide them
> when the user views the project list. This patch implements that
> feature, and the previous one fixes a bug I noticed along the way.
>
> Matt
Cannot you do this with new $export_auth_hook gitweb configuration
variable, added by Alexander Gavrilov in
dd7f5f1 (gitweb: Add a per-repository authorization hook.)
It is used in check_export_ok subroutine, and is is checked also when
getting list of project from file
>From gitweb/INSTALL
- Finally, it is possible to specify an arbitrary perl subroutine that
will be called for each project to determine if it can be exported.
The subroutine receives an absolute path to the project as its only
parameter.
For example, if you use mod_perl to run the script, and have dumb
http protocol authentication configured for your repositories, you
can use the following hook to allow access only if the user is
authorized to read the files:
$export_auth_hook = sub {
use Apache2::SubRequest ();
use Apache2::Const -compile => qw(HTTP_OK);
my $path = "$_[0]/HEAD";
my $r = Apache2::RequestUtil->request;
my $sub = $r->lookup_file($path);
return $sub->filename eq $path
&& $sub->status == Apache2::Const::HTTP_OK;
};
> gitweb/gitweb.perl | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
No documentation, in gitweb/README or gitweb/INSTALL
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 5357bcc..085cc60 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1144,7 +1144,7 @@ sub untabify {
>
> sub project_in_list {
> my $project = shift;
> - # Tell git_get_projects_list to include forks.
> + # Tell git_get_projects_list to include forks and hidden repositories.
> my @list = git_get_projects_list(undef, 1);
> return @list && scalar(grep { $_->{'path'} eq $project } @list);
> }
> @@ -2174,15 +2174,18 @@ sub git_get_projects_list {
> # 'git%2Fgit.git Linus+Torvalds'
> # 'libs%2Fklibc%2Fklibc.git H.+Peter+Anvin'
> # 'linux%2Fhotplug%2Fudev.git Greg+Kroah-Hartman'
> + #
> + # 1 in the third field hides the project from user-visible lists, e.g.:
> + # 'linux%2Fembargoed-security-fixes.git John+Doe 1'
I guess I'd rather use _last_ field, in the event we add project
description to project list file format.
> my %paths;
> open my ($fd), $projects_list or return;
> PROJECT:
> while (my $line = <$fd>) {
> chomp $line;
> - my ($path, $owner) = split ' ', $line;
> + my ($path, $owner, $hidden) = split ' ', $line;
> $path = unescape($path);
> $owner = unescape($owner);
> - if (!defined $path) {
> + if (!defined $path || ($hidden && !$for_strict_export)) {
> next;
> }
> if ($filter ne '') {
> @@ -2227,6 +2230,8 @@ sub git_get_projects_list {
> return @list;
> }
>
> +# This is used to look up the owner of a project the user is already allowed to
> +# see, so we shouldn't omit hidden repositories.
> our $gitweb_project_owner = undef;
> sub git_get_project_list_from_file {
>
> @@ -2241,7 +2246,7 @@ sub git_get_project_list_from_file {
> open (my $fd , $projects_list);
> while (my $line = <$fd>) {
> chomp $line;
> - my ($pr, $ow) = split ' ', $line;
> + my ($pr, $ow, $hidden) = split ' ', $line;
> $pr = unescape($pr);
> $ow = unescape($ow);
> $gitweb_project_owner->{$pr} = to_utf8($ow);
> --
> 1.6.1.rc2.27.gc7114
>
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] gitweb: support hiding projects from user-visible lists
From: Jakub Narebski @ 2008-12-13 22:05 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <m3ljujg2eh.fsf@localhost.localdomain>
By the way, your message [PATCH 2/2] should be threaded, i.e. be
response to [PATCH 1/2] (or to cover letter [PATCH 0/2]), to not
mistake it with other [PATCH 2/2] patches.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: gitweb and unicode special characters
From: Jakub Narebski @ 2008-12-13 22:08 UTC (permalink / raw)
To: Edward Z. Yang; +Cc: git
In-Reply-To: <ghv8rf$47v$1@ger.gmane.org>
"Edward Z. Yang" <edwardzyang@thewritingpot.com> writes:
> Jakub Narebski wrote:
> > Sidenote: There is probably one exception we want to add, namely not
> > escape '\r' at the end of line, to be able to deal better with DOS
> > line endings (\r\n).
>
> I'm sorry, but I have to disagree. I find being able to see \r
> line-endings in the pretty-printed format is exceedingly useful for
> figuring out if a file has been checked in with the wrong line-endings.
> The number of files that must have \r line endings are vanishingly small
> (BAT files are perhaps the one example I can think of right now).
Well, it is a bit annoying if you have checked file with wrong line
endings, and just noticed this... I was thinking about adding '(DOS)'
or something indicator at the bottom of 'blob' and 'blame' views, but
I guess I can live with '\r'...
In short: I agree, that was not a good idea.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git weekly news: 2008-50
From: Jakub Narebski @ 2008-12-13 22:18 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812121710u7755b8a9m87dd134b0c8b04ea@mail.gmail.com>
"Felipe Contreras" <felipe.contreras@gmail.com> writes:
> This week I'm trying to address some of the issues mentioned here. I
> still would like people to request user accounts to this blog if they
> wish to make some git related posts.
>
> http://gitlog.wordpress.com/2008/12/13/git-weekly-links-2008-50/
>
> == Articles ==
>
> Why Subversion does not suck
> http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx
[...]
Thanks a lot. I quite like the new format, both HTML version on blog,
and the format used here in this email.
P.S. Small nitpick: you have changed the title of blog post, but not
subject of email.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH try 2] gitweb: Add option to put a trailing slash on pathinfo-style project URLs
From: Giuseppe Bilotta @ 2008-12-13 22:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matt McCutchen, git
In-Reply-To: <m3tz97g329.fsf@localhost.localdomain>
On Sat, Dec 13, 2008 at 10:47 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> Matt McCutchen <matt@mattmccutchen.net> writes:
>
>> My Web site uses pathinfo mode and some rewrite magic to show the gitweb
>> interface at the URL of the real repository directory (which users also
>> pull from). In this case, it's desirable to end generated links to the
>> project in a trailing slash so the Web server doesn't have to redirect
>> the client to add the slash. This patch adds a second element to the
>> "pathinfo" feature configuration to control the trailing slash.
>>
>> Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
>
> Did you check that it does not confuse gitweb if filename parameter is
> passed using pathinfo? Gitweb used to rely on final '/' to
> distinguish directory pathnames from ordinary pathnames, but I think
> currently thanks to the fact that gitweb now embeds action in pathinfo
> URL, and does not need to guess type, it is not an issue.
>
> Or only project URLs (i.e. only with project parameter, i.e. only
> "http://git.example.com/project.git/" but not other path_info links)
> have trailing slash added?
>
> Errr... I see that it adds trailing slash only for project-only
> path_info links, but the commit message was not entirely clear for me.
If indeed the additional / is only asked for in summary view, I think
there's no need for a feature toggle, we can always put it there. If
not, I'm really curious about seeing the rewrite rules (they might
also be worth adding to the gitweb documentation as examples of 'power
usage').
--
Giuseppe "Oblomov" Bilotta
^ 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