* Trouble with git-svn when upstream svn URL changed
From: Seth Falcon @ 2006-12-08 17:43 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi,
One of the repositories I have been tracking with git-svn was
reorganized and the path that I have been tracking is now in a new
location.
I was hoping that the following would work:
git clone orig new
cd new
git svn rebuild $NEW_URL
I also tried
git svn rebuild --remote $NEW_URL
This have some output that looked reasonable (svn rev nums and git
sha1's). But git svn fetch does nothing and I don't seem to have any
of the new content. Am I using this incorrectly?
I guess I can create a fresh git repos using git-svn init and then
fetch all of my dev branches from the original repository.
git version 1.4.4.1.g03c8-dirty (no changes to git-svn)
Thanks,
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Jakub Narebski @ 2006-12-08 17:44 UTC (permalink / raw)
To: git
In-Reply-To: <elc6j2$vej$1@sea.gmane.org>
Han-Wen Nienhuys wrote:
> From 105d331aee95c0cf3610ac0d2fd4aa7688bd5211 Mon Sep 17 00:00:00 2001
This line is not needed.
> From: Han-Wen Nienhuys <hanwen@xs4all.nl>
> Date: Fri, 8 Dec 2006 18:07:56 +0100
>
> GIT can now be built in a separate builddirectory. This is done as
> follows:
>
> mkdir build
> cd build
> $my_git_dir/configure
> make
Perhaps we should add this to INSTALL file, or to comments in either
Makefile, or configure.ac?
> In this case, configure creates an empty directory tree based on the
> source directory, and wraps Makefiles from source directory in the
> build directory. The rest of the functionality is delivered with the
> VPATH feature of Make.
>
> To make this work the Makefile should not mention ./ explicitly in
> rules, but rather use $< and $^ to automatically look in the source
> dir too.
>
> perl/Makefile and perl/Makefile.PL need special massaging because perl
> is not VPATH aware.
>
> Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
Very nicely written commit message. Good work.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-08 17:40 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <45799B02.3010102@zytor.com>
H. Peter Anvin wrote:
> Jeff Garzik wrote:
>>
>> This is quite nice and easy, if memory-only caching works for the
>> situation: http://www.danga.com/memcached/
>>
>> There are APIs for C, Perl, and plenty of other languages.
>>
>
> Memory-only caching is kind of nasty. Memory is a premium resource on
> kernel.org.
hmmm. Well, I have been wondering why nobody ever came up with a
system-wide local (==disk) cache for remote and/or calculated objects.
Maybe its time to do something about that.
I've been in a daemon-writing mood lately.
Jeff
^ permalink raw reply
* [PATCH] Allow building GIT in a different directory from the source directory
From: Han-Wen Nienhuys @ 2006-12-08 17:15 UTC (permalink / raw)
To: git
From 105d331aee95c0cf3610ac0d2fd4aa7688bd5211 Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Fri, 8 Dec 2006 18:07:56 +0100
GIT can now be built in a separate builddirectory. This is done as
follows:
mkdir build
cd build
$my_git_dir/configure
make
In this case, configure creates an empty directory tree based on the
source directory, and wraps Makefiles from source directory in the
build directory. The rest of the functionality is delivered with the
VPATH feature of Make.
To make this work the Makefile should not mention ./ explicitly in
rules, but rather use $< and $^ to automatically look in the source
dir too.
perl/Makefile and perl/Makefile.PL need special massaging because perl
is not VPATH aware.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Makefile | 21 ++++++++++++---------
config.mak.in | 9 ++++-----
configure.ac | 34 ++++++++++++++++++++++++++++++++++
generate-cmdlist.sh | 2 +-
perl/Makefile | 4 ++++
perl/Makefile.PL | 16 +++++++++++++---
6 files changed, 68 insertions(+), 18 deletions(-)
diff --git a/Makefile b/Makefile
index cb9b745..3ed57ec 100644
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ all:
#
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
- @$(SHELL_PATH) ./GIT-VERSION-GEN
+ @$(SHELL_PATH) $(srcdir)/GIT-VERSION-GEN
-include GIT-VERSION-FILE
uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
@@ -110,7 +110,7 @@ uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
CFLAGS = -g -O2 -Wall
LDFLAGS =
-ALL_CFLAGS = $(CFLAGS)
+ALL_CFLAGS = $(CFLAGS) -I.
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
@@ -120,7 +120,10 @@ datadir = $(prefix)/share
GIT_datadir = $(datadir)/git-core
gitexecdir = $(bindir)
template_dir = $(GIT_datadir)/templates/
-# DESTDIR=
+srcdir = .
+
+# this is usually set on the make command line.
+DESTDIR=
# default configuration for gitweb
GITWEB_CONFIG = gitweb_config.perl
@@ -598,8 +601,8 @@ git-merge-recur$X: git-merge-recursive$X
$(BUILT_INS): git$X
rm -f $@ && ln git$X $@
-common-cmds.h: Documentation/git-*.txt
- ./generate-cmdlist.sh > $@+
+common-cmds.h: $(wildcard $(srcdir)/Documentation/git-*.txt)
+ $(srcdir)/generate-cmdlist.sh $(srcdir)/Documentation/ > $@+
mv $@+ $@
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
@@ -609,7 +612,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's!@@GIT_datadir@@!$(GIT_datadir)!g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
- $@.sh >$@+
+ $^ >$@+
chmod +x $@+
mv $@+ $@
@@ -630,7 +633,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.perl >$@+
+ $^ >$@+
chmod +x $@+
mv $@+ $@
@@ -674,7 +677,7 @@ git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
-e '/@@GITWEB_CGI@@/d' \
-e '/@@GITWEB_CSS@@/r gitweb/gitweb.css' \
-e '/@@GITWEB_CSS@@/d' \
- $@.sh > $@+
+ $< > $@+
chmod +x $@+
mv $@+ $@
@@ -821,7 +824,7 @@ install: all
fi
$(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
- $(INSTALL) -m755 git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
+ $(INSTALL) -m755 $(srcdir)/git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/config.mak.in b/config.mak.in
index 9a57840..bfbbf46 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -10,17 +10,16 @@ TAR = @TAR@
prefix = @prefix@
exec_prefix = @exec_prefix@
bindir = @bindir@
-#gitexecdir = @libexecdir@/git-core/
+mandir=@mandir@
+
+## unused, but necessary for some autoconf versions (?)
datarootdir = @datarootdir@
-template_dir = @datadir@/git-core/templates/
-mandir=@mandir@
srcdir = @srcdir@
-VPATH = @srcdir@
export exec_prefix mandir
-export srcdir VPATH
+export srcdir
NEEDS_SSL_WITH_CRYPTO=@NEEDS_SSL_WITH_CRYPTO@
NO_OPENSSL=@NO_OPENSSL@
diff --git a/configure.ac b/configure.ac
index 34e3478..403c410 100644
--- a/configure.ac
+++ b/configure.ac
@@ -5,6 +5,7 @@ AC_PREREQ(2.59)
AC_INIT([git], [@@GIT_VERSION@@], [git@vger.kernel.org])
AC_CONFIG_SRCDIR([git.c])
+srcdir=`cd $srcdir && pwd`
config_file=config.mak.autogen
config_append=config.mak.append
@@ -334,6 +335,39 @@ GIT_PARSE_WITH(iconv))
AC_CONFIG_FILES(["${config_file}":"${config_in}":"${config_append}"])
AC_OUTPUT
+if test "$srcdir" != "."; then
+
+ ## if we're building in another directory
+ ## we need to set it up like the sourcedir
+ for d in `cd $srcdir && find . -type d -print | grep -v '\.git'` ;
+ do
+ if test ! -d $d ; then
+ echo creating $d
+ mkdir $d
+ fi
+
+ if test -f $srcdir/$d/Makefile ; then
+
+ dnl [[]] is to keep m4 happy
+ depth=`echo $d/ | sed -e 's!^\./!!g' -e 's![[^/]]*/!../!g'`
+ echo creating $d/Makefile
+
+ if test "$depth" = ""; then
+ INCLUDE_AUTOGEN="include config.mak.autogen" ;
+ else
+ INCLUDE_AUTOGEN="srcdir=$srcdir"
+ fi
+
+ cat << EOF > $d/Makefile
+$INCLUDE_AUTOGEN
+VPATH = $srcdir/$d
+export VPATH
+include $srcdir/$d/Makefile
+EOF
+
+ fi
+ done
+fi
## Cleanup
rm -f "${config_append}"
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 5450918..e744fbb 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -47,6 +47,6 @@ do
x
s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
p
- }' "Documentation/git-$cmd.txt"
+ }' "$1/git-$cmd.txt"
done
echo "};"
diff --git a/perl/Makefile b/perl/Makefile
index bd483b0..e912191 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -28,6 +28,10 @@ $(makfile): ../GIT-CFLAGS Makefile
echo instlibdir: >> $@
echo ' echo $(instdir_SQ)' >> $@
else
+
+PERL_SRCDIR=$(srcdir)/perl
+export PERL_SRCDIR
+
$(makfile): Makefile.PL ../GIT-CFLAGS
'$(PERL_PATH_SQ)' $< FIRST_MAKEFILE='$@' PREFIX='$(prefix_SQ)'
endif
diff --git a/perl/Makefile.PL b/perl/Makefile.PL
index de73235..8a1251d 100644
--- a/perl/Makefile.PL
+++ b/perl/Makefile.PL
@@ -8,21 +8,31 @@ instlibdir:
MAKE_FRAG
}
-my %pm = ('Git.pm' => '$(INST_LIBDIR)/Git.pm');
+
+$src_prefix = '';
+if (!($ENV{'PERL_SRCDIR'} eq "")) {
+ $src_prefix = $ENV{'PERL_SRCDIR'} . "/"
+}
+
+
+my %pm = ("$src_prefix/Git.pm" => '$(INST_LIBDIR)/Git.pm');
+
+
# We come with our own bundled Error.pm. It's not in the set of default
# Perl modules so install it if it's not available on the system yet.
eval { require Error };
if ($@) {
- $pm{'private-Error.pm'} = '$(INST_LIBDIR)/Error.pm';
+ $pm{"$src_prefix/private-Error.pm"} = '$(INST_LIBDIR)/Error.pm';
}
my %extra;
$extra{DESTDIR} = $ENV{DESTDIR} if $ENV{DESTDIR};
+
WriteMakefile(
NAME => 'Git',
- VERSION_FROM => 'Git.pm',
+ VERSION_FROM => "$src_prefix/Git.pm",
PM => \%pm,
%extra
);
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* Re: git pull and merging.
From: Josef Weidendorfer @ 2006-12-08 17:23 UTC (permalink / raw)
To: Santi Béjar
Cc: Junio C Hamano, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <8aa486160612071756s18f9530cr7ed26e4b7b47d1de@mail.gmail.com>
On Friday 08 December 2006 02:56, Santi Béjar wrote:
> > [remote "repo"]
> > url = ...
> > fetch = branch1
> > fetch = branch2
> >
> > [branch "mybranch1"]
> > remote = repo
> > merge = branch1
> >
> > actually looks fine, and is the only possible way.
> > But still, this does not work.
>
> It works for me.
>
> > You have to specify
> >
> > merge = refs/heads/branch1
>
> It does not.
>
> The merge line must match exactly the remote part of the refspec.
Yes, you are right; I just looked it up in git-parse-remote.
Sorry about any confusion.
>
> >
> > That's confusing (perhaps I can come up with a patch
> > to allow "branch1" alone).
> >
> > So probably the best way is to write some more detailed
> > explanation into the docu ...
>
> Perhaps that the branch.<name>.remote and branch.<name>.merge have the
> equivalent meaning as the parameters of git-pull?
We want to fetch multiple refs from one remote in a row. So what
are you proposing? That branch.<name>.merge has to exactly
specify one remote? I do not think this is needed.
Actually, I am really for a new branch.<name>.localmerge option,
and keeping branch.<name>.merge (but not advertising it).
^ permalink raw reply
* [PATCH] Add support for building documentation in separate build-dir too.
From: Han-Wen Nienhuys @ 2006-12-08 17:16 UTC (permalink / raw)
To: git
From 6969e092758f65e8b4b3875ab3050cd0c049cc60 Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Fri, 8 Dec 2006 18:09:23 +0100
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Documentation/Makefile | 33 ++++++++++++++++++++-------------
1 files changed, 20 insertions(+), 13 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c00f5f6..51cd707 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,6 +1,6 @@
MAN1_TXT= \
$(filter-out $(addsuffix .txt, $(ARTICLES) $(SP_ARTICLES)), \
- $(wildcard git-*.txt)) \
+ $(wildcard $(here-srcdir)/git-*.txt)) \
gitk.txt
MAN7_TXT=git.txt
@@ -33,8 +33,15 @@ man7dir=$(mandir)/man7
INSTALL?=install
--include ../config.mak.autogen
+ifndef srcdir
+srcdir=..
+endif
+
+here-srcdir=$(srcdir)/Documentation
+ASCIIDOC_CONF=$(here-srcdir)/asciidoc.conf
+
+-include ../config.mak.autogen
#
# Please note that there is a minor bug in asciidoc.
# The version after 6.0.3 _will_ include the patch found here:
@@ -63,9 +70,9 @@ install: man
#
# Determine "include::" file references in asciidoc files.
#
-doc.dep : $(wildcard *.txt) build-docdep.perl
+doc.dep : $(wildcard $(here-srcdir)/*.txt) build-docdep.perl
rm -f $@+ $@
- perl ./build-docdep.perl >$@+
+ perl $(lastword $^) >$@+
mv $@+ $@
-include doc.dep
@@ -80,35 +87,35 @@ clean:
rm -f *.xml *.html *.1 *.7 howto-index.txt howto/*.html doc.dep README
%.html : %.txt
- asciidoc -b xhtml11 -d manpage -f asciidoc.conf $<
+ asciidoc -b xhtml11 -d manpage -f $(ASCIIDOC_CONF) $<
%.1 %.7 : %.xml
- xmlto -m callouts.xsl man $<
+ xmlto --searchpath $(here-srcdir)/ -m callouts.xsl man $<
%.xml : %.txt
- asciidoc -b docbook -d manpage -f asciidoc.conf $<
+ asciidoc -b docbook -d manpage -f $(ASCIIDOC_CONF) $<
git.html: git.txt README
glossary.html : glossary.txt sort_glossary.pl
cat $< | \
- perl sort_glossary.pl | \
+ perl $(lastword $^) | \
asciidoc -b xhtml11 - > glossary.html
-howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
+howto-index.txt: howto-index.sh $(wildcard $(here-srcdir)/howto/*.txt)
rm -f $@+ $@
- sh ./howto-index.sh $(wildcard howto/*.txt) >$@+
+ sh $^ >$@+
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
- asciidoc -b xhtml11 $*.txt
+ asciidoc -b xhtml11 $<
WEBDOC_DEST = /pub/software/scm/git/docs
-$(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
+$(patsubst %.txt,%.html,$(wildcard $(here-srcdir)/howto/*.txt)): %.html : %.txt
rm -f $@+ $@
sed -e '1,/^$$/d' $< | asciidoc -b xhtml11 - >$@+
mv $@+ $@
install-webdoc : html
- sh ./install-webdoc.sh $(WEBDOC_DEST)
+ sh $(here-srcdir)/install-webdoc.sh $(WEBDOC_DEST)
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with explicit path.
From: Han-Wen Nienhuys @ 2006-12-08 17:13 UTC (permalink / raw)
To: git
git-sh-setup isn't a 'normal' binary, in that it should be called by
bash only and not run in a subshell. Therefore, it should not be installed
in a executable directory, but rather in $prefix/share/git-core/
From 4cefe86667d01ecc912c1f9d8b78c831c33792a1 Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Wed, 6 Dec 2006 13:27:16 +0100
Subject:
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Makefile | 10 ++++++++--
git-am.sh | 2 +-
git-applymbox.sh | 2 +-
git-applypatch.sh | 2 +-
git-bisect.sh | 2 +-
git-checkout.sh | 2 +-
git-clean.sh | 2 +-
git-commit.sh | 2 +-
git-fetch.sh | 2 +-
git-instaweb.sh | 2 +-
git-lost-found.sh | 2 +-
git-merge.sh | 2 +-
git-pull.sh | 2 +-
git-quiltimport.sh | 2 +-
git-rebase.sh | 2 +-
git-repack.sh | 2 +-
git-request-pull.sh | 2 +-
git-reset.sh | 2 +-
git-resolve.sh | 2 +-
git-revert.sh | 2 +-
git-tag.sh | 2 +-
git-verify-tag.sh | 2 +-
22 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index a1861de..cb9b745 100644
--- a/Makefile
+++ b/Makefile
@@ -116,8 +116,10 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
+datadir = $(prefix)/share
+GIT_datadir = $(datadir)/git-core
gitexecdir = $(bindir)
-template_dir = $(prefix)/share/git-core/templates/
+template_dir = $(GIT_datadir)/templates/
# DESTDIR=
# default configuration for gitweb
@@ -166,7 +168,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-resolve.sh git-revert.sh git-sh-setup.sh \
+ git-resolve.sh git-revert.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
@@ -550,6 +552,7 @@ endif
# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
+GIT_datadir_SQ = $(subst ','\'',$(GIT_datadir))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
@@ -604,6 +607,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's!@@GIT_datadir@@!$(GIT_datadir)!g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@+
chmod +x $@+
@@ -816,6 +820,8 @@ install: all
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
$(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
+ $(INSTALL) -m755 git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/git-am.sh b/git-am.sh
index afe322b..b9dfcf0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -5,7 +5,7 @@
USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
[--interactive] [--whitespace=<option>] <mbox>...
or, when resuming [--skip | --resolved]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git var GIT_COMMITTER_IDENT >/dev/null || exit
diff --git a/git-applymbox.sh b/git-applymbox.sh
index 5569fdc..eaab50d 100755
--- a/git-applymbox.sh
+++ b/git-applymbox.sh
@@ -19,7 +19,7 @@
## git-am is supposed to be the newer and better tool for this job.
USAGE='[-u] [-k] [-q] [-m] (-c .dotest/<num> | mbox) [signoff]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git var GIT_COMMITTER_IDENT >/dev/null || exit
diff --git a/git-applypatch.sh b/git-applypatch.sh
index 8df2aee..7ddf5d3 100755
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -12,7 +12,7 @@
##
USAGE='<msg> <patch> <info> [<signoff>]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
case "$#" in 3|4) ;; *) usage ;; esac
diff --git a/git-bisect.sh b/git-bisect.sh
index 6da31e8..6fa92e2 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -10,7 +10,7 @@ git bisect visualize show bisect status in gitk.
git bisect replay <logfile> replay bisection log
git bisect log show bisect log.'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
sq() {
@@PERL@@ -e '
diff --git a/git-checkout.sh b/git-checkout.sh
index 737abd0..beea113 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -2,7 +2,7 @@
USAGE='[-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
SUBDIRECTORY_OK=Sometimes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
old_name=HEAD
old=$(git-rev-parse --verify $old_name 2>/dev/null)
diff --git a/git-clean.sh b/git-clean.sh
index 3834323..7a7ce6e 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -13,7 +13,7 @@ LONG_USAGE='Clean untracked files from the working directory
When optional <paths>... arguments are given, the paths
affected are further limited to those that match them.'
SUBDIRECTORY_OK=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
ignored=
ignoredonly=
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..5a388f5 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -5,7 +5,7 @@
USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
branch=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD)
diff --git a/git-fetch.sh b/git-fetch.sh
index 4eecf14..efe44ea 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -2,7 +2,7 @@
#
USAGE='<fetch-options> <repository> <refspec>...'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
. git-parse-remote
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 16cd351..ae9fbc1 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -6,7 +6,7 @@ USAGE='[--start] [--stop] [--restart]
[--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
[--module-path=<path> (for Apache2 only)]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
case "$GIT_DIR" in
/*)
diff --git a/git-lost-found.sh b/git-lost-found.sh
index b928f2c..5f612f2 100755
--- a/git-lost-found.sh
+++ b/git-lost-found.sh
@@ -2,7 +2,7 @@
USAGE=''
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
if [ "$#" != "0" ]
then
diff --git a/git-merge.sh b/git-merge.sh
index a948878..b83b4b9 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -5,7 +5,7 @@
USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [--reflog-action=<action>] [-m=<merge-message>] <commit>+'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
LF='
'
diff --git a/git-pull.sh b/git-pull.sh
index e23beb6..8c0f292 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -6,7 +6,7 @@
USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 10135da..2f1e7b7 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,7 +1,7 @@
#!/bin/sh
USAGE='--dry-run --author <author> --patches </path/to/quilt/patch/directory>'
SUBDIRECTORY_ON=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
dry_run=""
quilt_author=""
diff --git a/git-rebase.sh b/git-rebase.sh
index 25530df..3220291 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -27,7 +27,7 @@ Example: git-rebase master~1 topic
/ --> /
D---E---F---G master D---E---F---G master
'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
diff --git a/git-repack.sh b/git-repack.sh
index f150a55..e85f0b6 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -5,7 +5,7 @@
USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
no_update_info= all_into_one= remove_redundant=
local= quiet= no_reuse_delta= extra=
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 4eacc3a..fd02d55 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -8,7 +8,7 @@ USAGE='<commit> <url> [<head>]'
LONG_USAGE='Summarizes the changes since <commit> to the standard output,
and includes <url> in the message generated.'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
revision=$1
url=$2
diff --git a/git-reset.sh b/git-reset.sh
index c0feb44..4c4f551 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -1,7 +1,7 @@
#!/bin/sh
USAGE='[--mixed | --soft | --hard] [<commit-ish>]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
update=
reset_type=--mixed
diff --git a/git-resolve.sh b/git-resolve.sh
index 36b90e3..4c2d7da 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -10,7 +10,7 @@ echo 'WARNING: Please use git-merge or git-pull instead.' >&2
sleep 2
USAGE='<head> <remote> <merge-message>'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
dropheads() {
rm -f -- "$GIT_DIR/MERGE_HEAD" \
diff --git a/git-revert.sh b/git-revert.sh
index 6eab3c7..8a30297 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -18,7 +18,7 @@ case "$0" in
* )
die "What are you talking about?" ;;
esac
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
no_commit=
while case "$#" in 0) break ;; esac
diff --git a/git-tag.sh b/git-tag.sh
index d53f94c..a7d6223 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -3,7 +3,7 @@
USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
message_given=
annotate=
diff --git a/git-verify-tag.sh b/git-verify-tag.sh
index 36f171b..d265150 100755
--- a/git-verify-tag.sh
+++ b/git-verify-tag.sh
@@ -2,7 +2,7 @@
USAGE='<tag>'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
verbose=
while case $# in 0) break;; esac
--
1.4.4.1.gc9922-dirty
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply related
* doc bug?
From: Han-Wen Nienhuys @ 2006-12-08 17:07 UTC (permalink / raw)
To: git
Hi,
while messing with GIT's build system, I got
**
asciidoc -b docbook -d manpage -f ../Documentation/asciidoc.conf ../Documentation/git-tools.txt
ERROR: git-tools.txt: line 2: malformed manpage title
ERROR: git-tools.txt: line 6: first section must be named NAME
ERROR: git-tools.txt: line 9: malformed NAME section body
FAILED: /home/lilydev/vc/git/Documentation/git-tools.txt: line 9: unexpected error:
------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 3639, in asciidoc
document.translate()
File "/usr/bin/asciidoc", line 966, in translate
Header.translate()
File "/usr/bin/asciidoc", line 1123, in translate
attrs['manname'] = string.strip(mo.group('manname'))
AttributeError: 'NoneType' object has no attribute 'group'
------------------------------------------------------------
**
is this a new problem? I'm on FC6, with asciidoc 7.0.2
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 17:04 UTC (permalink / raw)
To: Jeff Garzik
Cc: Linus Torvalds, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <457998C8.3050601@garzik.org>
Jeff Garzik wrote:
>
> This is quite nice and easy, if memory-only caching works for the
> situation: http://www.danga.com/memcached/
>
> There are APIs for C, Perl, and plenty of other languages.
>
Memory-only caching is kind of nasty. Memory is a premium resource on
kernel.org.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-08 16:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612080830380.3516@woody.osdl.org>
Linus Torvalds wrote:
> I could write a simple C caching thing that just hashes the CGI arguments
> and uses a hash to create a cache (and proper lock-files etc to serialize
> access to a particular cache object while it's being created) fairly
> easily, but I'm pretty sure people would much prefer a mod_perl thing just
> to avoid the fork/exec overhead with Apache (I think mod_perl allows
> Apache to run perl scripts without it), and that means I'm not the right
> person any more.
>
> Not that I'm the right person anyway, since I don't have a web server set
> up on my machine to even test with ;)
>
> Linus
>
> -
> 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
>
This is quite nice and easy, if memory-only caching works for the
situation: http://www.danga.com/memcached/
There are APIs for C, Perl, and plenty of other languages.
Jeff
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 16:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Rogan Dawes, Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612080830380.3516@woody.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 8 Dec 2006, H. Peter Anvin wrote:
>> This goes back to the "gitweb needs native caching" again.
>
> It should be fairly easy to add a caching layer, but I wouldn't do it
> inside gitweb itself - it gets too mixed up. It would be better to have
> it as a separate front-end, that just calls gitweb for anything it doesn't
> find in the cache.
>
If you want to do side effect generation of cache contents, it might not
be possible to do it that way. At the very least gitweb needs to be
aware of how to explicitly enter things into the cache.
All of this isn't really all that hard; I have implemented all that
stuff for diffview, for example (when generating a single diff hunk, you
naturally end up producing all of them, so you want to have them
preemptively cached.)
> I could write a simple C caching thing that just hashes the CGI arguments
> and uses a hash to create a cache (and proper lock-files etc to serialize
> access to a particular cache object while it's being created) fairly
> easily, but I'm pretty sure people would much prefer a mod_perl thing just
> to avoid the fork/exec overhead with Apache (I think mod_perl allows
> Apache to run perl scripts without it), and that means I'm not the right
> person any more.
True about mod_perl. Haven't messed with that myself, either.
fork/exec really is very cheap on Linux, so it's not a huge deal.
> Not that I'm the right person anyway, since I don't have a web server set
> up on my machine to even test with ;)
Heh :)
-hpa
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-08 16:35 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Rogan Dawes, Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <45798FE2.9040502@zytor.com>
On Fri, 8 Dec 2006, H. Peter Anvin wrote:
>
> This goes back to the "gitweb needs native caching" again.
It should be fairly easy to add a caching layer, but I wouldn't do it
inside gitweb itself - it gets too mixed up. It would be better to have
it as a separate front-end, that just calls gitweb for anything it doesn't
find in the cache.
I could write a simple C caching thing that just hashes the CGI arguments
and uses a hash to create a cache (and proper lock-files etc to serialize
access to a particular cache object while it's being created) fairly
easily, but I'm pretty sure people would much prefer a mod_perl thing just
to avoid the fork/exec overhead with Apache (I think mod_perl allows
Apache to run perl scripts without it), and that means I'm not the right
person any more.
Not that I'm the right person anyway, since I don't have a web server set
up on my machine to even test with ;)
Linus
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 16:16 UTC (permalink / raw)
To: Rogan Dawes
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <4579611F.5010303@dawes.za.net>
Rogan Dawes wrote:
>
> How about extending gitweb to check to see if there already exists a
> cached version of these pages, before recreating them?
>
This goes back to the "gitweb needs native caching" again.
^ permalink raw reply
* Re: [PATCH 1/2] Allow users to require source branch on git-checkout -b.
From: J. Bruce Fields @ 2006-12-08 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vac1yoq3r.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 07, 2006 at 10:31:52PM -0800, Junio C Hamano wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> >> But my main complaint is just that I wouldn't want to see the behavior
> >> of defaulting to HEAD--behavior which is simple, easy to explain, and
> >> shared by most other git commands--by something significantly more
> >> complicated. That's more a complaint about Junio's suggestion than
> >> yours, though.
> >
> > True, defaulting to HEAD is something that is done almost everywhere.
> > Changing it for `git checkout -b` may surprise a lot of people,
> > almost as much as --index vs. --cached.
>
> I did not mean to change the default to something other than
> HEAD depending on the configuration.
Right, I understand that behavior in existing repositories is not
changed...
> > (3) otherwise, it barfs if you do not give an explicit
> > branch-point.
>
> ... but a newly created repositories would have an
> allowbranchbydefault entry on "master" (and only on "master"),
> which means new people would be prevented from making mistakes
> when on a non-master branch 'foo':
... my concern is the default behavior on newly created repositories,
which (unless I've misunderstood) would become more complicated.
> But I do not deeply care about this.
OK. Me neither, to be honest.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jonas Fonseca @ 2006-12-08 15:38 UTC (permalink / raw)
To: Rogan Dawes
Cc: Jakub Narebski, H. Peter Anvin, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <4579775C.2010608@dawes.za.net>
On 12/8/06, Rogan Dawes <discard@dawes.za.net> wrote:
> NOTE: This caching could be problematic for the "changed 2 hours ago"
> notation for various branches/files, etc. But however we implement the
> caching, we'd have this problem.
It could be solved using ECMAScript (if that is an option): Include an exact
time stamp or something that browsers not supporting ECMAScript can
show and others browsers can change the time stamp to make it relative
and do the coloring/highlighting of recent activity. This could also slightly
speed up the script and it might be better to provide an exact time stamp
by default if aggressive caching is applied.
--
^ permalink raw reply
* Re: For all you darcs lovers: git-hunk-commit
From: Johannes Schindelin @ 2006-12-08 15:37 UTC (permalink / raw)
To: Matthias Kestenholz; +Cc: git
In-Reply-To: <1165568153.21747.11.camel@localhost.localdomain>
Hi,
On Fri, 8 Dec 2006, Matthias Kestenholz wrote:
> On Wed, 2006-12-06 at 01:36 +0100, Johannes Schindelin wrote:
> > But in this case, bash was faster to script and debug, and unless people
> > speak up, saying "I want that feature badly!", I do not plan to do
> > anything with it.
>
> This feature is _very_ handy and I think it would be great if this
> became part of the default git distribution.
Note that it requires a relatively new bash version ATM, because of the
"while read line; do ...; done < <(cmd)" construct. I have another version
which substitutes a temporary file for that, but I keep thinking that a
graphical tool, such as git-gui, would be more appropriate. BTW I just did
it in bash, because I wanted to learn about these famous bash arrays.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable)
From: Jakub Narebski @ 2006-12-08 15:36 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vwt54yb8d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> * The 'maint' branch has produced a new release 1.4.4.2
What happened to "[ANNOUNCE] GIT 1.4.4.2" thread?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Rogan Dawes @ 2006-12-08 14:31 UTC (permalink / raw)
To: Jakub Narebski
Cc: H. Peter Anvin, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <200612081438.25493.jnareb@gmail.com>
Jakub Narebski wrote:
> Dnia piątek 8. grudnia 2006 13:57, Rogan Dawes napisał:
>> How about extending gitweb to check to see if there already exists a
>> cached version of these pages, before recreating them?
>>
>> e.g. structure the temp dir in such a way that each project has a place
>> for cached pages. Then, before performing expensive operations, check to
>> see if a file corresponding to the requested page already exists. If it
>> does, simply return the contents of the file, otherwise go ahead and
>> create the page dynamically, and return it to the user. Do not create
>> cached pages in gitweb dynamically.
>
> This would add the need for directory for temporary files... well,
> it would be optional now...
>
It would still be optional. If the "cache" directory structure exists,
then use it, otherwise, continue as usual. All it would cost is a stat()
or two, I guess.
>> Then, in a post-update hook, for each of the expensive pages, invoke
>> something like:
>>
>> # delete the cached copy of the file, to force gitweb to recreate it
>> rm -f $git_temp/$project/rss
>> # get gitweb to recreate the page appropriately
>> # use a tmp file to prevent gitweb from getting confused
>> wget -O $git_temp/$project/rss.tmp \
>> http://kernel.org/gitweb.cgi?p=$project;a=rss
>> # move the tmp file into place
>> mv $git_temp/$project/rss.tmp $git_temp/$project/rss
>
> Good idea... although there are some page views which shouldn't change
> at all... well, with the possible exception of changes in gitweb output,
> and even then there are some (blob_plain and snapshot views) which
> doesn't change at all.
>
> It would be good to avoid removing them on push, and only remove
> them using some tmpwatch-like removal.
Well, my theory was that we would only cache pages that change when new
data enters the repo. So, using the push as the trigger is almost
guaranteed to be the right thing to do. New data indicates new rss
items, indicates an updated shortlog page, etc.
NOTE: This caching could be problematic for the "changed 2 hours ago"
notation for various branches/files, etc. But however we implement the
caching, we'd have this problem.
>> This way, we get the exact output returned from the usual gitweb
>> invocation, but we can now cache the result, and only update it when
>> there is a new commit that would affect the page output.
>>
>> This would also not affect those who do not wish to use this mechanism.
>> If the file does not exist, gitweb.cgi will simply revert to its usual
>> behaviour.
>
> Good idea. Perhaps I should add it to gitweb TODO file.
>
> Hmmm... perhaps it is time for next "[RFC] gitweb wishlist and TODO list"
> thread?
>
>> Possible complications are the content-type headers, etc, but you could
>> use the -s flag to wget, and store the server headers as well in the
>> file, and get the necessary headers from the file as you stream it.
>>
>> i.e. read the headers looking for ones that are "interesting"
>> (Content-Type, charset, expires) until you get a blank line, print out
>> the interesting headers using $cgi->header(), then just dump the
>> remainder of the file to the caller via stdout.
>
> No need for that. $cgi->header() is to _generate_ the headers, so if
> a file is saved with headers, we can just dump it to STDOUT; the possible
> exception is a need to rewrite 'expires' header, if it is used.
Good point. I guess one thing that will be incorrect in the headers is
the server date, but I doubt that anyone cares much. As you say, though,
this might relate to the expiry of cached content in upstream caches.
>
> Perhaps gitweb should generate it's own ETag instead of messing with
> 'expires' header?
Well, we can possibly eliminate the expires header entirely for dynamic
pages, and check the If-Modified-Since value against the timestamp of
the cached file, or the server date in the cached file, and return "304
Not Modified" responses. That would also help to reduce the load on the
server, by only returning the headers, and not the entire response.
The downside is that it would prevent upstream proxies from caching this
data for us.
Regards,
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Alex Riesen @ 2006-12-08 14:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20061207221503.GA4990@steel.home>
On 12/7/06, Alex Riesen <fork0@t-online.de> wrote:
> > Maybe you want "assume unchanged"?
>
> If that is core.ignoreState you mean, than maybe this is what I mean.
> I haven't tried it yet (now I wonder myself why I haven't tried it).
> But (I'm repeating myself, in
> <81b0412b0612060235l5d5f93d0hd1aaf34924f7783@mail.gmail.com>)
> I do not really understand how it _can_ help: "I ask because it does
> not ignore stat info, as the name implies. Because if it would,
> there'd be no point of calling lstat at all, wouldn't it?" That last
> question was about refresh_cache_entry - it calls lstat
> unconditionally.
>
> Still, I guess I'll have to try it.
>
Tried. No noticeable difference:
$ git repo-config core.ignorestat true; time gup --refresh
real 0m8.004s
user 0m1.936s
sys 0m5.702s
$ git repo-config core.ignorestat false; time gup --refresh
real 0m7.787s
user 0m1.890s
sys 0m5.703s
$
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-08 13:38 UTC (permalink / raw)
To: Rogan Dawes
Cc: H. Peter Anvin, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <4579611F.5010303@dawes.za.net>
Dnia piątek 8. grudnia 2006 13:57, Rogan Dawes napisał:
> H. Peter Anvin wrote:
>> Olivier Galibert wrote:
>>> On Thu, Dec 07, 2006 at 11:16:58AM -0800, H. Peter Anvin wrote:
>>>> Unfortunately, the most common queries are also extremely expensive.
With newer gitweb, which tries to do the same using less git commands,
some of queries (summary, heads, tags pages) should be less expensive.
>>> Do you have a top-ten of queries ? That would be the ones to optimize
>>> for.
>>
>> The front page, summary page of each project, and the RSS feed for each
>> project.
>
> How about extending gitweb to check to see if there already exists a
> cached version of these pages, before recreating them?
>
> e.g. structure the temp dir in such a way that each project has a place
> for cached pages. Then, before performing expensive operations, check to
> see if a file corresponding to the requested page already exists. If it
> does, simply return the contents of the file, otherwise go ahead and
> create the page dynamically, and return it to the user. Do not create
> cached pages in gitweb dynamically.
This would add the need for directory for temporary files... well,
it would be optional now...
> Then, in a post-update hook, for each of the expensive pages, invoke
> something like:
>
> # delete the cached copy of the file, to force gitweb to recreate it
> rm -f $git_temp/$project/rss
> # get gitweb to recreate the page appropriately
> # use a tmp file to prevent gitweb from getting confused
> wget -O $git_temp/$project/rss.tmp \
> http://kernel.org/gitweb.cgi?p=$project;a=rss
> # move the tmp file into place
> mv $git_temp/$project/rss.tmp $git_temp/$project/rss
Good idea... although there are some page views which shouldn't change
at all... well, with the possible exception of changes in gitweb output,
and even then there are some (blob_plain and snapshot views) which
doesn't change at all.
It would be good to avoid removing them on push, and only remove
them using some tmpwatch-like removal.
> This way, we get the exact output returned from the usual gitweb
> invocation, but we can now cache the result, and only update it when
> there is a new commit that would affect the page output.
>
> This would also not affect those who do not wish to use this mechanism.
> If the file does not exist, gitweb.cgi will simply revert to its usual
> behaviour.
Good idea. Perhaps I should add it to gitweb TODO file.
Hmmm... perhaps it is time for next "[RFC] gitweb wishlist and TODO list"
thread?
> Possible complications are the content-type headers, etc, but you could
> use the -s flag to wget, and store the server headers as well in the
> file, and get the necessary headers from the file as you stream it.
>
> i.e. read the headers looking for ones that are "interesting"
> (Content-Type, charset, expires) until you get a blank line, print out
> the interesting headers using $cgi->header(), then just dump the
> remainder of the file to the caller via stdout.
No need for that. $cgi->header() is to _generate_ the headers, so if
a file is saved with headers, we can just dump it to STDOUT; the possible
exception is a need to rewrite 'expires' header, if it is used.
Perhaps gitweb should generate it's own ETag instead of messing with
'expires' header?
--
Jakub Narebski
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Rogan Dawes @ 2006-12-08 12:57 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <4578722E.9030402@zytor.com>
H. Peter Anvin wrote:
> Olivier Galibert wrote:
>> On Thu, Dec 07, 2006 at 11:16:58AM -0800, H. Peter Anvin wrote:
>>> Unfortunately, the most common queries are also extremely expensive.
>>
>> Do you have a top-ten of queries ? That would be the ones to optimize
>> for.
>
> The front page, summary page of each project, and the RSS feed for each
> project.
>
> -hpa
How about extending gitweb to check to see if there already exists a
cached version of these pages, before recreating them?
e.g. structure the temp dir in such a way that each project has a place
for cached pages. Then, before performing expensive operations, check to
see if a file corresponding to the requested page already exists. If it
does, simply return the contents of the file, otherwise go ahead and
create the page dynamically, and return it to the user. Do not create
cached pages in gitweb dynamically.
Then, in a post-update hook, for each of the expensive pages, invoke
something like:
# delete the cached copy of the file, to force gitweb to recreate it
rm -f $git_temp/$project/rss
# get gitweb to recreate the page appropriately
# use a tmp file to prevent gitweb from getting confused
wget -O $git_temp/$project/rss.tmp \
http://kernel.org/gitweb.cgi?p=$project;a=rss
# move the tmp file into place
mv $git_temp/$project/rss.tmp $git_temp/$project/rss
This way, we get the exact output returned from the usual gitweb
invocation, but we can now cache the result, and only update it when
there is a new commit that would affect the page output.
This would also not affect those who do not wish to use this mechanism.
If the file does not exist, gitweb.cgi will simply revert to its usual
behaviour.
Possible complications are the content-type headers, etc, but you could
use the -s flag to wget, and store the server headers as well in the
file, and get the necessary headers from the file as you stream it.
i.e. read the headers looking for ones that are "interesting"
(Content-Type, charset, expires) until you get a blank line, print out
the interesting headers using $cgi->header(), then just dump the
remainder of the file to the caller via stdout.
^ permalink raw reply
* git-commit: select which files to commit while editing the commit message
From: Pazu @ 2006-12-08 12:36 UTC (permalink / raw)
To: git
Junio's reworking of the git-commit documentation, and the ensuing discussion
about what is commited, and how do you select that, made me remember how much I
liked SVK -- particularly, how much I liked to remove files from the commit
message template, and have them removed from the commit.
At first, I thought "great opportunity to contribute my first patch to git",
until I realized that git-commit is written in bash, and my brain refuses to
understand that. Yep, I'm that bad. So I'm writing this, and maybe someone
well-versed in bash will find this a good idea and code it :-)
For those not familiar with SVK, if you remove the files mentioned in the commit
template (that "here are the files that you're about to commit" part), SVK won't
commit them. For example, if I modify a couple of files in git, and execute 'git
commit -a', an editor will popup showing something like this:
# Please enter the commit message for your changes.
# (Comment lines starting with '#' will not be included)
# On branch refs/heads/next
# Updated but not checked in:
# (will commit)
#
# modified: perl/Makefile
# modified: var.c
Here's where the magic would happen. Removing the line "modified: var.c" would
remove var.c from this commit. Of course, the template message should be
modified to tell the user he can do that.
So, what do you think about this?
-- Pazu
^ permalink raw reply
* Re: [PATCH 5/5] rerere: add the diff command
From: Jakub Narebski @ 2006-12-08 12:07 UTC (permalink / raw)
To: git
In-Reply-To: <1165574977365-git-send-email-normalperson@yhbt.net>
Eric Wong wrote:
> Sometimes I like to see what I'm recording resolutions for and
> what's changed during a resolution.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
> git-rerere.perl | 7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
Documentation, please?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Salikh Zakirov @ 2006-12-08 11:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7pik51b.fsf@assigned-by-dhcp.cox.net>
Junio Hamano wrote:
> +Instead of staging files after each individual change, you can
> +tell `git commit` to notice the changes to the tracked files in
> +your working tree and do corresponding `git add` and `git rm`
> +for you.
This part is confusing as hell to anyone having any experience
with either CVS, SVN, Hg or Monotone, as doing "corresponding `git add`
and `git rm`" commands automatically will be interpreted as adding
untracked files automatically, which is not the case here.
^ permalink raw reply
* Re: Commit f84871 breaks build on OS X
From: Brian Gernhardt @ 2006-12-08 11:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612072340w6af9df37y25a1d15773a3f8d8@mail.gmail.com>
On Dec 8, 2006, at 2:40 AM, Alex Riesen wrote:
>> Now, I am CLUELESS about what MakeMaker does, but would this
>> help?
>
> Much better.
> Works here. Others?
Perfect!
^ 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