* Re: A few more fixups to gitweb
From: Luben Tuikov @ 2006-08-01 20:10 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git, Martin Langhoff, Matthias Lederhofer
In-Reply-To: <7vzmep2icr.fsf_-_@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> One thing to note. Please make sure that you do not see
> anything in Apache error log after you make your changes. I do
> not remember the details but kernel.org folks were very unhappy
> earlier when gitweb spewed stuff into the error log, and if I
> recall correctly things that output to the error stream were not
> friendly to the http-server cache for some reason.
I've been meaning to mention this as well. Gitweb patches,
especially recent ones, need more (thorough) testing, before
posted to the list for inclusion.
Luben
^ permalink raw reply
* Re: [PATCH] gitweb: fill in gitweb configuration by Makefile
From: Martin Waitz @ 2006-08-01 19:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eakc16$p77$1@sea.gmane.org>
hoi :)
On Mon, Jul 31, 2006 at 09:38:26AM +0200, Jakub Narebski wrote:
> There are currently two version variables in gitweb: the version of the
> script, and the version of git binaries used. They might be different.
> But now that gitweb is bundled with git, perhaps we could use compile-time
> git version as gitweb version
updated patch below:
+++
Generate gitweb/gitweb.cgi to reduce the need to patch gitweb.cgi by
the end user.
The GIT installation directory is already known by the Makefile, and can be
inserted directly into gitweb.
All other gitweb configuration parameters can now be specified by providing
GITWEB_* variables while building GIT. These are described in gitweb/README.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
Makefile | 25 +++++++++++++++++++++++--
gitweb/.gitignore | 1 +
gitweb/README | 17 +++++++++++++++++
gitweb/{gitweb.cgi => gitweb.pl} | 15 +++++++--------
4 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index 15864e2..0d66c6a 100644
--- a/Makefile
+++ b/Makefile
@@ -116,6 +116,13 @@ template_dir = $(prefix)/share/git-core/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
# DESTDIR=
+# default configuration for gitweb
+GITWEB_SITENAME =
+GITWEB_PROJECTROOT = /pub/git
+GITWEB_LIST =
+GITWEB_HOMETEXT = indextext.html
+GITWEB_CSS = gitweb.css
+
export prefix bindir gitexecdir template_dir GIT_PYTHON_DIR
CC = gcc
@@ -514,7 +521,7 @@ LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk
+all: $(ALL_PROGRAMS) $(BUILT_INS) git$X gitk gitweb/gitweb.cgi
all:
$(MAKE) -C templates
@@ -572,6 +579,20 @@ git-status: git-commit
cp $< $@+
mv $@+ $@
+gitweb/gitweb.cgi: gitweb/gitweb.pl
+ rm -f $@ $@+
+ sed -e '1s|#!.*perl|#!$(PERL_PATH_SQ)|' \
+ -e 's|@@GIT_VERSION@@|$(GIT_VERSION)|g' \
+ -e 's|@@GIT_BINDIR@@|$(bindir)|g' \
+ -e 's|@@GITWEB_SITENAME@@|$(GITWEB_SITENAME)|g' \
+ -e 's|@@GITWEB_PROJECTROOT@@|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|@@GITWEB_LIST@@|$(GITWEB_LIST)|g' \
+ -e 's|@@GITWEB_HOMETEXT@@|$(GITWEB_HOMETEXT)|g' \
+ -e 's|@@GITWEB_CSS@@|$(GITWEB_CSS)|g' \
+ $< >$@+
+ chmod +x $@+
+ mv $@+ $@
+
git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
rm -f $@ $@+
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
@@ -582,7 +603,7 @@ git-instaweb: git-instaweb.sh gitweb/git
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
- $@.sh | sed "s|/usr/bin/git|$(bindir)/git|" > $@+
+ $@.sh > $@+
chmod +x $@+
mv $@+ $@
diff --git a/gitweb/.gitignore b/gitweb/.gitignore
new file mode 100644
index 0000000..e83127e
--- /dev/null
+++ b/gitweb/.gitignore
@@ -0,0 +1 @@
+gitweb.cgi
diff --git a/gitweb/README b/gitweb/README
index 8d67276..ed939e2 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -5,5 +5,22 @@ The one working on:
From the git version 1.4.0 gitweb is bundled with git.
+
+How to configure gitweb for your local system:
+
+You can specify the following configuration variables when building GIT:
+ * GITWEB_SITENAME
+ Shown in the title of all generated pages, defaults to the servers name.
+ * GITWEB_PROJECTROOT
+ The root directory for all projects shown by gitweb.
+ * GITWEB_LIST
+ points to a directory to scan for projects (defaults to project root)
+ or to a file for explicit listing of projects.
+ * GITWEB_HOMETEXT
+ points to an .html file which is included on the gitweb project
+ overview page.
+ * GITWEB_CSS
+ Points to the location where you put gitweb.css on your web server.
+
Any comment/question/concern to:
Kay Sievers <kay.sievers@vrfy.org>
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.pl
similarity index 100%
rename from gitweb/gitweb.cgi
rename to gitweb/gitweb.pl
index e5fca63..20dd901 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.pl
@@ -17,18 +17,18 @@ use Fcntl ':mode';
binmode STDOUT, ':utf8';
our $cgi = new CGI;
-our $version = "267";
+our $version = "@@GIT_VERSION@@";
our $my_url = $cgi->url();
our $my_uri = $cgi->url(-absolute => 1);
our $rss_link = "";
# core git executable to use
# this can just be "git" if your webserver has a sensible PATH
-our $GIT = "/usr/bin/git";
+our $GIT = "@@GIT_BINDIR@@/git";
# absolute fs-path which will be prepended to the project path
#our $projectroot = "/pub/scm";
-our $projectroot = "/home/kay/public_html/pub/scm";
+our $projectroot = "@@GITWEB_PROJECTROOT@@";
# version of the core git binary
our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
@@ -44,17 +44,16 @@ our $home_link = $my_uri;
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
-our $site_name = $ENV{'SERVER_NAME'} || "Untitled";
+our $site_name = "@@GITWEB_SITENAME@@" || $ENV{'SERVER_NAME'} || "Untitled";
# html text to include at home page
-our $home_text = "indextext.html";
+our $home_text = "@@GITWEB_HOMETEXT@@";
# URI of default stylesheet
-our $stylesheet = "gitweb.css";
+our $stylesheet = "@@GITWEB_CSS@@";
# source of projects list
-#our $projects_list = $projectroot;
-our $projects_list = "index/index.aux";
+our $projects_list = "@@GITWEB_LIST@@" || "$projectroot";
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
--
1.4.2.rc2.gf055
--
Martin Waitz
^ permalink raw reply related
* Re: path-restricted gitk with tags showing up?
From: Olivier Galibert @ 2006-08-01 19:33 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <20060801231329.82d934a2.vsu@altlinux.ru>
On Tue, Aug 01, 2006 at 11:13:29PM +0400, Sergey Vlasov wrote:
> On Tue, 1 Aug 2006 19:42:10 +0200 Olivier Galibert wrote:
>
> > I'd like to do a (f.i) gitk include/sound/asound.h but still see the
> > commits which are in the DAG delimited by the alsa commits and have
> > tags attached. The aim is to know what changes where in what released
> > kernel version. Is there a way to do that?
>
> Since git-1.4.0 gitk shows this information in the "Follows:" and
> "Precedes:" lines for each commit (you need to enable "Display nearby
> tags" in preferences). In your case, the "Precedes" line will show the
> first kernel version which included the change.
>
> Note that loading this information takes some time; gitk tries to load
> it in background, so you may see empty "Follows" and "Precedes" lines
> for some time.
Works rather well, thanks.
OG.
^ permalink raw reply
* Re: path-restricted gitk with tags showing up?
From: Sergey Vlasov @ 2006-08-01 19:13 UTC (permalink / raw)
To: Olivier Galibert; +Cc: git
In-Reply-To: <20060801174210.GA81699@dspnet.fr.eu.org>
[-- Attachment #1: Type: text/plain, Size: 748 bytes --]
On Tue, 1 Aug 2006 19:42:10 +0200 Olivier Galibert wrote:
> I'd like to do a (f.i) gitk include/sound/asound.h but still see the
> commits which are in the DAG delimited by the alsa commits and have
> tags attached. The aim is to know what changes where in what released
> kernel version. Is there a way to do that?
Since git-1.4.0 gitk shows this information in the "Follows:" and
"Precedes:" lines for each commit (you need to enable "Display nearby
tags" in preferences). In your case, the "Precedes" line will show the
first kernel version which included the change.
Note that loading this information takes some time; gitk tries to load
it in background, so you may see empty "Follows" and "Precedes" lines
for some time.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: path-restricted gitk with tags showing up?
From: Linus Torvalds @ 2006-08-01 18:39 UTC (permalink / raw)
To: Olivier Galibert; +Cc: git
In-Reply-To: <20060801174210.GA81699@dspnet.fr.eu.org>
On Tue, 1 Aug 2006, Olivier Galibert wrote:
>
> I'd like to do a (f.i) gitk include/sound/asound.h but still see the
> commits which are in the DAG delimited by the alsa commits and have
> tags attached. The aim is to know what changes where in what released
> kernel version. Is there a way to do that?
Not right now. It should be fairly easy to add a flag that marks all
tagged commits (or, indeed, anything that is reachable from .git/refs/) as
"TREECHANGE" so that they aren't optimized away, but we don't have
anything like that right now at least.
A small exercise for somebody who wants to get into git, perhaps? Hint,
hint..
Linus
^ permalink raw reply
* path-restricted gitk with tags showing up?
From: Olivier Galibert @ 2006-08-01 17:42 UTC (permalink / raw)
To: git
I'd like to do a (f.i) gitk include/sound/asound.h but still see the
commits which are in the DAG delimited by the alsa commits and have
tags attached. The aim is to know what changes where in what released
kernel version. Is there a way to do that?
OG.
^ permalink raw reply
* Would you mind adding the OLS paper to the webpage?
From: André Goddard Rosa @ 2006-08-01 17:25 UTC (permalink / raw)
To: Git Mailing List
Hi, all!
Could you please add the Ottawa Linux Symposium git paper to the
homepage, please?
http://members.cox.net/junkio/200607-ols.pdf
Very nice description and presentation, Junio! :)
Thank you so much,
--
[]s,
André Goddard
^ permalink raw reply
* Re: setting up git-cvsserver
From: Johannes Schindelin @ 2006-08-01 16:23 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060801154906.GA18772@informatik.uni-freiburg.de>
Hi,
On Tue, 1 Aug 2006, Uwe Zeisberger wrote:
> I cannot checkout a git repo via cvs, I think the only problem is, that
> I don't know how to specify the CVSROOT:
>
> fs-n1:~# grep git- /etc/inetd.conf
> 2402 stream tcp nowait root /usr/local/sbin/git-cvsserver pserver
>From Documentation/git-cvsserver.txt:
-- snip --
Note: In some cases, you need to pass the 'pserver' argument twice for
git-cvsserver to see it. So the line would look like
------
cvspserver stream tcp nowait nobody git-cvsserver pserver pserver
-- snap --
So, maybe this solves your problem?
OTOH it might be cleverer to use SSH transport to begin with.
Hth,
Dscho
^ permalink raw reply
* setting up git-cvsserver
From: Uwe Zeisberger @ 2006-08-01 15:49 UTC (permalink / raw)
To: git
Hello,
I cannot checkout a git repo via cvs, I think the only problem is, that
I don't know how to specify the CVSROOT:
fs-n1:~# grep git- /etc/inetd.conf
2402 stream tcp nowait root /usr/local/sbin/git-cvsserver pserver
fs-n1:~# GIT_DIR=/data/vcs/git/LxNETES-2.4/bl.git git var -l
core.repositoryformatversion=0
core.filemode=true
gitcvs.enabled=1
GIT_COMMITTER_IDENT=root <root@fs-n1.fsforth.de> 1154447177 +0200
GIT_AUTHOR_IDENT=root <root@fs-n1.fsforth.de> 1154447177 +0200
uzeisberger@io:~$ cvs -d :pserver:fs-c:2402/data/vcs/git/LxNETES-2.4/bl.git login
Logging in to :pserver:uzeisberger@fs-c:2402/data/vcs/git/LxNETES-2.4/bl.git
CVS password:
cvs [login aborted]: unrecognized auth response from fs-c: Unknown command BEGIN VERIFICATION REQUEST at /usr/local/sbin/git-cvsserver line 132, <STDIN> line 1.
uzeisberger@io:~$ cvs -d :pserver:fs-c:2402/data/vcs/git/LxNETES-2.4/bl.git co master
cvs [checkout aborted]: unrecognized auth response from fs-c: Unknown command BEGIN AUTH REQUEST at /usr/local/sbin/git-cvsserver line 132, <STDIN> line 1.
cvs version is 1.12.13 (Debian)
git-cvsserver is from v1.4.2-rc2-gbc9e1b8
rest of git is 1.4.0
probably I'm just too stupid to read and understand the docs...
Best regards
Uwe
--
Uwe Zeisberger
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
^ permalink raw reply
* Re: Strange cogito behaviour
From: Andy Parkins @ 2006-08-01 15:41 UTC (permalink / raw)
To: git
In-Reply-To: <20060801151258.GB3923@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1458 bytes --]
On Tuesday 2006 August 01 16:12, Jeff King wrote:
> A cogito fetch without a branch specifier defaults to the remote HEAD,
> not master. This is the documented behavior (see cg-branch-add(1)). I
> agree it is confusing (I also thought it was a bug until I looked it up
Fair enough. If it is working as intended, then I have no complaint.
> > The script then continues with
> > * Switch repo1 back to master branch
> > * Update repo2
> > This time repo2 doesn't change. So I'm more confused :-)
>
> This is because repo2's master is already at the branch, and repo1 is a
> subset of that history. There is no need to merge since repo2 already
> contains all of the commits in repo1 (plus another one which is only on
> the branch in repo1).
I think I see now. repo2 is neither repo1#master nor repo1#branch because it
actually went like this:
* repo1 cloned to repo2, repo2#master is repo1#master
* repo2 fetches repo1#branch and /merges/ those changes
* repo1#HEAD switched to HEAD=master
* repo2 fetch does nothing because repo2 is actually
repo1#master + repo1#branch, hence is newer than both
repo1#master and repo1#branch
That explanation seems to fit exactly with the observed results, so would seem
to be plausible.
Thank you for your help; I of course withdraw my bug report and apologise for
bothering you all :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Greeting!
From: Carola @ 2006-08-01 15:23 UTC (permalink / raw)
To: Andreas
Hallo !
I'm a very young and energetic lady! I have very positive attitude to life and people. I do enjoy new experience life can offer me: to see new interesting places, to meet new people.
I do try to enjoy every moment of life and accept everything the way it comes without complaining.
Though my life seems to be quite enjoyable there's one important thing missing. It's LOVE!
Without my beloved one, my soul mate, my King my life is not completed.
I wish i coud find him very soon so that we could share together every momement of the life-time romance!
What about you? Could you be my King? If answer is "yes" - you can find more about me
http://dating-foryou.com/passion/
a rivederci,
Carola
If you think that you were subscribed by mistake for this mail
delivery or if your email has been added without your permission,
please, visit http://dating-foryou.com/passion/ and unsubscribe from our mails.
^ permalink raw reply
* Better Success, world-changing
From: Rodrick Lopez @ 2006-08-01 15:20 UTC (permalink / raw)
To: git
Your cre dit doesn't matter to us! If you OWN real est ate
and want IMMEDIATE9 cash to spend ANY way you like, or simply wish
to LOWER your monthly paym ents by a third or more, here are the dea ls
we have TODAY (hurry, these ofers will expre TONIGHT):
$488,000.00 at a 3.67,% fixed-rateN
$372,000.00 at a 3.90,% variable-rate9
$492,000.00 at a 3.21,% interest-onlyR
$248,000.00 at a 3.36,% fixed-rateV
$198,000.00 at a 3.55,% variable-rate5
Hurry, when these deals are gone, they are gone Simply fill out this one-min ute form...
Don't worry about approval, your cre dit will not disqualify you!
http://EIZRX8.kruelo.net
I've come here. That's what I want here. A strange and very new feeling
nearest hill a hundred steps from the rocks. "Got it? Let's go."
clothes had stuck to his body, to his burned skin, and now something was
had been washed away, his face--also contrary to expectation --turned out to
artificial tone.
hill, which he could also see, completely bare, its slope covered with brown
and unexpectedly, even for myself, took a heavy mug from the counter and
"Fine. And next time I'll let you have it in the teeth. If you're still
and Redrick was amazed to see how short his terrible, endless path had been,
Redrick, ears clogged by the noise, turned and saw a bright red spot quickly
realized that they were trapped. The heat was increasing, over- whelming
^ permalink raw reply
* Re: Strange cogito behaviour
From: Jeff King @ 2006-08-01 15:12 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200608011053.25112.andyparkins@gmail.com>
On Tue, Aug 01, 2006 at 10:53:24AM +0100, Andy Parkins wrote:
> It does the following:
> * Create a repository, repo1, add a file to it
> * Create a branch inside repo1 and change the file in it
> * Switches repo1 to master branch
> * Clones repo1 to repo2
> * Switches repo1 to alternate branch
> * Updates repo2
>
> The odd behaviour is that repo2 changes in the update to show the branch
> contents in the working copy. The only actions that has happened in repo1 is
A cogito fetch without a branch specifier defaults to the remote HEAD,
not master. This is the documented behavior (see cg-branch-add(1)). I
agree it is confusing (I also thought it was a bug until I looked it up
:) ). If you want to always fetch from the master, you must say so
explicitly:
$ cg-clone repo1#master repo2
> The script then continues with
> * Switch repo1 back to master branch
> * Update repo2
> This time repo2 doesn't change. So I'm more confused :-)
This is because repo2's master is already at the branch, and repo1 is a
subset of that history. There is no need to merge since repo2 already
contains all of the commits in repo1 (plus another one which is only on
the branch in repo1).
-Peff
^ permalink raw reply
* [RFC/PATCH] gitweb: include perl files for configuration
From: Matthias Lederhofer @ 2006-08-01 13:53 UTC (permalink / raw)
To: git
In-Reply-To: <200607292239.11034.jnareb@gmail.com>
gitweb will first include all files after __DATA__ and then
$GITWEB_CONFIG
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
I really hate upgrading gitweb because every time I've to copy the
configuration part from the old script to the new one. I do some
regexp to find the values for some configuration values so I'd prefer
to include a perl file instead of a normal configuration file.
For example I'd use this with this patch:
$GIT = "/usr/local/bin/git";
$stylesheet = "/gitweb.css";
if ($ENV{'SCRIPT_NAME'} =~ m#^/([a-z0-9-]+)/#) {
$projectroot = "/home/$1";
$home_text = $projectroot."/gitweb.html";
$projects_list = $projectroot."/gitweb.list";
} else {
$projectroot = "/home";
$home_text = "/www/gitweb.html";
$projects_list = "/www/gitweb.list";
}
In this setup there is one subdirectory per-user which contains a
symlink to ../gitweb.cgi allowing them to maintain their own gitweb.
Later (see gitweb.pl post) the Makefile could also add the path to the
configuration file automatically if a certain variable is set (by
appending the filename to gitweb.cgi).
Using __DATA__ instead of a variable holding the filename allows to
add the configuration file easily without editing the file in an
editor or trying to replace some part (without breaking something)
using sed.
This patch is on top of my last patch (user configuration cleanup).
---
gitweb/gitweb.cgi | 35 ++++++++++++++++++++++++++++++++---
1 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index ca2ef70..96f8852 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -23,6 +23,12 @@ ##
## BEGIN USER CONFIGURATION
##
+# You can let gitweb 'do' (perldoc -f do) configuration files after this
+# configuration section to override the values. The configuration files
+# will be executed in this order:
+# - files after __DATA__ (first file first)
+# - file in the $GITWEB_CONFIG environment variable
+
# absolute fs-path which will be prepended to the project path
our $projectroot = "/pub/git";
@@ -67,10 +73,31 @@ ##
## END USER CONFIGURATION
##
-# version of the core git binary
-our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
-
our $version = "267";
+# die_error uses this, circumvents some warnings
+our $git_version = 'unknown';
+
+# 'do' configuration files
+for my $file (<DATA>, $ENV{'GITWEB_CONFIG'}) {
+ next if (!defined($file));
+ $file =~ s/\r?\n$//;
+ if (! -e $file) {
+ warn("configuration file '$file' does not exist");
+ die_error('500 Internal Server Error', 'Configuration error');
+ }
+ undef $@;
+ undef $!;
+ next if (defined(do($file)));
+ if ($@) {
+ warn("parse error in configuration file '$file': $@");
+ } else {
+ warn("error in configuration file '$file': $!");
+ }
+ die_error('500 Internal Server Error', 'Configuration error');
+}
+
+# version of the core git binary
+$git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
# create temp directory
if (! -d $git_temp) {
@@ -2608,3 +2635,5 @@ sub git_opml {
"</body>\n".
"</opml>\n";
}
+
+__DATA__
--
1.4.2.rc2.g4713
^ permalink raw reply related
* [PATCH] gitweb: clean up user configuration part
From: Matthias Lederhofer @ 2006-08-01 12:48 UTC (permalink / raw)
To: git
In-Reply-To: <200607292239.11034.jnareb@gmail.com>
* add a marker where the user configuration starts/ends
* replaced the two $projectroot = lines
* add a comment to $projectlist
* reorder the variables
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
---
I tried to put the variables at top which will be edited most likely
(cannot have sane default values).
---
gitweb/gitweb.cgi | 58 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/gitweb/gitweb.cgi b/gitweb/gitweb.cgi
index 9448b72..ca2ef70 100755
--- a/gitweb/gitweb.cgi
+++ b/gitweb/gitweb.cgi
@@ -18,44 +18,42 @@ use File::Find qw();
binmode STDOUT, ':utf8';
our $cgi = new CGI;
-our $version = "267";
-our $my_url = $cgi->url();
-our $my_uri = $cgi->url(-absolute => 1);
-our $rss_link = "";
-# core git executable to use
-# this can just be "git" if your webserver has a sensible PATH
-our $GIT = "/usr/bin/git";
+##
+## BEGIN USER CONFIGURATION
+##
# absolute fs-path which will be prepended to the project path
-#our $projectroot = "/pub/scm";
-our $projectroot = "/home/kay/public_html/pub/scm";
+our $projectroot = "/pub/git";
-# version of the core git binary
-our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
+# source of projects list
+# file: list of projects, may use subdirectories
+# directory: all git repositories in the directory (not subdirectories)
+our $projects_list = "index/index.aux";
+#our $projects_list = $projectroot;
-# location for temporary files needed for diffs
-our $git_temp = "/tmp/gitweb";
-if (! -d $git_temp) {
- mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
-}
+# html text to include at home page
+our $home_text = "indextext.html";
-# target of the home link on top of all pages
-our $home_link = $my_uri;
+# core git executable to use
+# this can just be "git" if your webserver has a sensible PATH
+our $GIT = "/usr/bin/git";
# name of your site or organization to appear in page titles
# replace this with something more descriptive for clearer bookmarks
our $site_name = $ENV{'SERVER_NAME'} || "Untitled";
-# html text to include at home page
-our $home_text = "indextext.html";
+our $my_url = $cgi->url();
+our $my_uri = $cgi->url(-absolute => 1);
+our $rss_link = "";
+# target of the home link on top of all pages
+our $home_link = $my_uri;
# URI of default stylesheet
our $stylesheet = "gitweb.css";
-# source of projects list
-#our $projects_list = $projectroot;
-our $projects_list = "index/index.aux";
+# location for temporary files needed for diffs
+our $git_temp = "/tmp/gitweb";
# default blob_plain mimetype and default charset for text/plain blob
our $default_blob_plain_mimetype = 'text/plain';
@@ -65,6 +63,20 @@ # file to use for guessing MIME types be
# (relative to the current git repository)
our $mimetypes_file = undef;
+##
+## END USER CONFIGURATION
+##
+
+# version of the core git binary
+our $git_version = qx($GIT --version) =~ m/git version (.*)$/ ? $1 : "unknown";
+
+our $version = "267";
+
+# create temp directory
+if (! -d $git_temp) {
+ mkdir($git_temp, 0700) || die_error("Couldn't mkdir $git_temp");
+}
+
# input validation and dispatch
our $action = $cgi->param('a');
if (defined $action) {
--
1.4.2.rc2.g4713
^ permalink raw reply related
* Re: Why I love GIT but use Subversion (was: GIT user survey)
From: Alex Riesen @ 2006-08-01 12:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jörg W Mittag, git
In-Reply-To: <Pine.LNX.4.63.0608011201030.17230@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> And for the notoriously difficult part: why not just bundle a cygwin
> environment, stripped-down to fit just the needs of git?
Because it's hard to get it not to conflict with existing or following
cygwin installtion.
^ permalink raw reply
* Re: Why I love GIT but use Subversion
From: Noel Grandin @ 2006-08-01 12:14 UTC (permalink / raw)
Cc: git
In-Reply-To: <46a038f90608010359w76819870g4dab0911410727b1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
Hi
They would probably be quite willing to have someone fork TortoiseSVN
and make a TortoiseGIT, which would save a lot of the hassle with
creating an installer, finding the WindowsExplorer hook APIs, etc, etc,
from scratch.
Especially since TortoiseSVN started by forking TortoiseCVS.
Regards,
Noel Grandin
Martin Langhoff wrote:
> On 8/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> And you _can_ do more: like Junio said, ask people you know who work on
>> Windows to help...
>
> Indeed, I think these guys need to hear from Jorg, see the "Mailing
> list" link:
>
> http://tortoisesvn.tigris.org/
>
>
> ;-)
>
> I know it's cheeky, but if you write a similarly polite rant/wishlist
> to the nice TortoiseSVN developers and they are interested, we can, as
> Junio said, help them out with GIT specifics.
>
> cheers,
>
>
> martin
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
NOTICE: This email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html
If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com
^ permalink raw reply
* Re: Diff format in packs
From: Jakub Narebski @ 2006-08-01 12:01 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0608011248530.17230@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> In another mail, you asked for a solution for the initial 700MB download.
> How about doing it like Linux-2.6, namely have a clean cut, and for those
> who want, they can load the historical repo, too, and graft it onto the
> current one?
Perhaps that would be incentive to finally make "lazy clone"/"shallow clone"
support in git.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Why I love GIT but use Subversion (was: GIT user survey)
From: Martin Langhoff @ 2006-08-01 10:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jörg W Mittag, git
In-Reply-To: <Pine.LNX.4.63.0608011201030.17230@wbgn013.biozentrum.uni-wuerzburg.de>
On 8/1/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> And you _can_ do more: like Junio said, ask people you know who work on
> Windows to help...
Indeed, I think these guys need to hear from Jorg, see the "Mailing list" link:
http://tortoisesvn.tigris.org/
;-)
I know it's cheeky, but if you write a similarly polite rant/wishlist
to the nice TortoiseSVN developers and they are interested, we can, as
Junio said, help them out with GIT specifics.
cheers,
martin
^ permalink raw reply
* Re: Diff format in packs
From: Johannes Schindelin @ 2006-08-01 10:59 UTC (permalink / raw)
To: Jon Smirl; +Cc: Martin Langhoff, Jakub Narebski, git
In-Reply-To: <9e4733910607311929j189eb6b9r6a804cc744290fdc@mail.gmail.com>
Hi Jon,
On Mon, 31 Jul 2006, Jon Smirl wrote:
> On 7/31/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > > would be to use cvs2svn to build the changeset database and then use
> > > cvsps to simply read the changesets out of it and build the git
> > > repository.
> >
> > Once cvs2svn has the db built, it should be easy to write a
> > perl/python script that mimics the output of cvsps.
>
> This is an efficiency problem.
In another mail, you asked for a solution for the initial 700MB download.
How about doing it like Linux-2.6, namely have a clean cut, and for those
who want, they can load the historical repo, too, and graft it onto the
current one?
I _think_ that with a new start, incremental git-cvsimport should still
work, if you do it cleverly. Obviously, it would _not_ have the full
history, but rather add onto the most recent revisions (incremental
git-cvsimport detects the revisions to import by author date IIRC).
Note that this method will _not_ work, if there are _new_ branches that
cvsps has problems with.
Ciao,
Dscho
^ permalink raw reply
* Re: Why I love GIT but use Subversion (was: GIT user survey)
From: Johannes Schindelin @ 2006-08-01 10:13 UTC (permalink / raw)
To: Jörg W Mittag; +Cc: git
In-Reply-To: <1prv3rw6ldo9s$.dlg@jwmittag.my-fqdn.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2921 bytes --]
Hi,
On Tue, 1 Aug 2006, Jörg W Mittag wrote:
> beware: this rant should have really been a blog post, but I don't have
> a blog ...;
This is the most polite rant I saw in a long time (including my own rants
;-).
> (a) a problem with Git being too specialized or (b) a problem with me
> choosing the wrong tool.
Definitely (a). But I might add "still".
> (Is there any unwritten rule in Git development that says that new
> features are only accepted if they add a new dependency on a new
> programming language? Currently Git is implemented in C, POSIX sh,
> Perl, Python, Tcl/Tk and C++ (if you include QGit) and I've already seen
> some Ruby code posted to the mailing list.)
Funny, this is also _my_ pet peeve. Although for different reasons: I do
not so much mind the dependency as the inconvenience with having different
programming styles, and often having to build the basic library functions
in every of these languages. Also, some people do not speak Perl or Bash
or Python
> The most pressing need for me would be a native Windows port. Where
> "native" means:
>
> - an installer package,
> - integration with the Windows Explorer,
> - handling of different line-ending encodings and
> - addressing the fact that things like SSH clients, diff, patch,
> merge, Perl, Python, Tcl/Tk, Bash and so on are usually not part
> of a standard Windows installation and are also notoriously
> difficult to install.
Let's see: the installer should not be a problem. (Several free options
come to mind).
Integration with the Windows Explorer is a bit tricky: first, most of the
Linux cracks have not worked with Windows APIs, and there is also the
problem that you need to convert the file names from/to braindead MS
why-not-put-a-colon-into-absolute-filenames names.
You do not need handling of different line-ending encodings _as long_ as
you have the same throughout your project.
And for the notoriously difficult part: why not just bundle a cygwin
environment, stripped-down to fit just the needs of git?
Of course, it would be a bit nicer if we had a MinGW32 port, and in fact,
I played with it a little. But the sad truth is: Windows lacks so many of
the good features of POSIX. It is not a project for just one afternoon to
make it run (although I admit that I have it running a "git-log -p"
successfully!).
> PS: I am well aware of the fact that Git is free software and that I
> could fix all those issues myself. However, the truth is, I can't.
> I'm stupid. I'm not a programmer. So, please don't take this as a
> demand or a request, merely a humble suggestion by a humble wannabe
> user, whom you are free to ignore.
Hey, you may be not a programmer, but what you just did was very valuable:
write about the problems you have with git.
And you _can_ do more: like Junio said, ask people you know who work on
Windows to help...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] Use tabs for indent in shell scripts
From: Jakub Narebski @ 2006-08-01 10:01 UTC (permalink / raw)
To: git
In-Reply-To: <7vr70023aj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> if [ -n "$GIT_SSL_NO_VERIFY" ]; then
>> - curl_extra_args="-k"
>> + curl_extra_args="-k"
>> fi
>
> Things like this makes some sense...
>
>> if test -n "$use_separate_remote" &&
>> - branch_name=`expr "z$name" : 'zheads/\(.*\)'`
>> + branch_name=`expr "z$name" : 'zheads/\(.*\)'`
>> then
>
> ... but not this, which is not just indent but an alignment.
Sorry, my mistake. Tabs for indent, spaces for align, of course. So discard
this chunk, please.
I'm not sure how to indent sequences like the following:
command arg \
arg arg arg \
arg arg arg
The above I think everybody would agree on.
command &&
command &&
command
command ||
command ||
command
Not so sure about above
[...]
> Also shell scripts tend to become too deeply indented, and 4-column
> indentation helps to keep things within typical screen width.
>
> In short, not very enthused.
I use tab-width 2 and script didn't get too indented. All changed scripts
except git-clone.sh fit in 80 column window for tab width 2, and the lines
in git-clone.sh which do not fit in 80 columns are not indented at all.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Strange cogito behaviour
From: Andy Parkins @ 2006-08-01 9:53 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 4411 bytes --]
Hello,
Hope this is the correct list for this report.
Attached is a script that demonstrates (I think) strange cogito behaviour.
Run it in a temporary directory.
It does the following:
* Create a repository, repo1, add a file to it
* Create a branch inside repo1 and change the file in it
* Switches repo1 to master branch
* Clones repo1 to repo2
* Switches repo1 to alternate branch
* Updates repo2
The odd behaviour is that repo2 changes in the update to show the branch
contents in the working copy. The only actions that has happened in repo1 is
a switch of the working directory to a different branch. It could easily be
that I've misunderstood what switch is doing, but the same operations using
git seem to work as I'd expect (script available if required).
The script then continues with
* Switch repo1 back to master branch
* Update repo2
This time repo2 doesn't change. So I'm more confused :-)
In case you don't want to run the script, sample output follows:
--------------------------------------------------------------
--- Make a project
--- Turn it into a repository, repo1
defaulting to local storage area
Adding file file
Committing initial tree ef18611ce9f2693e47a1b2df5e76613f53a9173c
Committed as f59933a07af5f12618deae8d33335621184ccc7c
--- Create a branch and change it's content
Creating new branch branch: f59933a07af5f12618deae8d33335621184ccc7c
Switching to branch branch...
M file
Committed as 88bc51f62dfa3d71fbc0140fdd48aa150215a632
--- Switch repo1 back to master
Switching to branch master...
--- Clone repo1 to repo2: repo2 is now the repo1#master
defaulting to local storage area
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' ->
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/master' ->
`.git/refs/heads/./.origin-fetching'
Fetching objects...
progress: 3 objects, 239 bytes
Fetching tags...
New branch: f59933a07af5f12618deae8d33335621184ccc7c
Cloned to repo2/ (origin /home/andyp/src/git-test/repo1 available as
branch "origin")
--- file now contains master contents
initial contents goes in master branch
--- Switch repo1 to branch again
Switching to branch branch...
--- Update repo2
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' ->
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/branch' ->
`.git/refs/heads/./.origin-fetching'
Fetching objects...
progress: 3 objects, 290 bytes
Fetching tags...
Tree change:
f59933a07af5f12618deae8d33335621184ccc7c:88bc51f62dfa3d71fbc0140fdd48aa150215a632
Applying changes...
Fast-forwarding f59933a07af5f12618deae8d33335621184ccc7c ->
88bc51f62dfa3d71fbc0140fdd48aa150215a632
on top of f59933a07af5f12618deae8d33335621184ccc7c ...
--- Show contents of both repositories
repo1/file:initial contents goes in master branch
repo1/file:added in branch - not in master
repo2/file:initial contents goes in master branch
repo2/file:added in branch - not in master
---
Why has repo2 changed? repo1 had its working copy switched
repo2 shouldn't care about what's in the local copy of repo1.
What exactly is repo2#master tracking? It's certainly not
repo1#master.
--- Switching repo1 back to master
Switching to branch master...
--- Updating repo2 again
Using hard links
Fetching head...
`/home/andyp/src/git-test/repo1/.git/HEAD' ->
`.git/refs/heads/./.origin-fetching'
`/home/andyp/src/git-test/repo1/.git/refs/heads/master' ->
`.git/refs/heads/./.origin-fetching'
Fetching objects...
Fetching tags...
Tree change:
88bc51f62dfa3d71fbc0140fdd48aa150215a632:f59933a07af5f12618deae8d33335621184ccc7c
Applying changes...
Branch already fully merged.
--- Show contents of both repositories
repo1/file:initial contents goes in master branch
repo2/file:initial contents goes in master branch
repo2/file:added in branch - not in master
---
Even more strange, switching repo1 back to "master" and
updating repo2, hasn't changed repo2. The first test showed that
repo2 is not tracking #master; but this test shows that repo2
is not tracking repo1 HEAD either. What is repo2 tracking?
(it seems that it's repo1#branch)
--------------------------------------------------------------
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #1.2: weird-cogito.sh --]
[-- Type: application/x-shellscript, Size: 1518 bytes --]
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Set User-Agent string in shell scripts used for fetching
From: Junio C Hamano @ 2006-08-01 9:51 UTC (permalink / raw)
To: git
In-Reply-To: <200608011136.54698.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> "Why?", meaning if we deliberately do so for some good reason?
>>
>> There isn't.
>>
>> git-http-fetch uses its own User-Agent string, but the shell
>> script wrappers that use curl executable do not bother setting
>> customized User-Agent string; that is why.
>
> So there :-)
Who said we want to? Actually I explicitly said we do not
bother ;-).
^ permalink raw reply
* Re: [PATCH 1/2] Use tabs for indent in shell scripts
From: Junio C Hamano @ 2006-08-01 9:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200608011134.52006.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> if [ -n "$GIT_SSL_NO_VERIFY" ]; then
> - curl_extra_args="-k"
> + curl_extra_args="-k"
> fi
Things like this makes some sense...
> if test -n "$use_separate_remote" &&
> - branch_name=`expr "z$name" : 'zheads/\(.*\)'`
> + branch_name=`expr "z$name" : 'zheads/\(.*\)'`
> then
... but not this, which is not just indent but an alignment.
> case "$2" in
> '')
> - usage ;;
> + usage ;;
> */*)
> - echo >&2 "'$2' is not suitable for an origin name"
> - exit 1
> + echo >&2 "'$2' is not suitable for an origin name"
> + exit 1
Also shell scripts tend to become too deeply indented, and 4-column
indentation helps to keep things within typical screen width.
In short, not very enthused.
^ 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