* read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Martin Langhoff @ 2006-12-28 20:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
On 12/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, just looking at the examples, it looks like memcached is
> fundamentally flawed, exactly the same way Apache mod_cache is
> fundamentally flawed.
memcached is really fast internally, but can be rather slow from the
POV of the client code, as it forces a costly
marshalling/unmarshalling of data. For perl-only situations where it
is OK to have per-server caches, I have been looking at
Cache::FastMmap. I will probably try to implement caching for the
projects, summary & log/shortlog pages using Cache::FastMap
And I'll do read-for-fill for it, and see how that goes.
(BTW, in the last week I've had to implement a similar
anti-thundering-herds cache in PHP using memcached and/or eaccelerator
-- a shmem cache -- and I've done a read-for-fill for both of them
that works reasonably well.)
cheers,
martin
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Pavel Roskin @ 2006-12-28 21:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyb159dn.fsf@assigned-by-dhcp.cox.net>
Hello!
On Wed, 2006-12-27 at 13:14 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> > For example, I clone the git repository anew, and I try to update it by
> > git-fetch a few days later. I get an error:
> >
> > * refs/remotes/origin/pu: not updating to non-fast forward branch 'pu'
> > of git://www.kernel.org/pub/scm/git/git
>
> Perhaps you would want something like this?
>
> if you are using separate remote layout:
>
> [remote "origin"]
> fetch = +refs/heads/pu:refs/remotes/origin/pu
> fetch = refs/heads/*:refs/remotes/origin/*
That works.
Actually, it's strange that I don't actually have refs/heads/pu
under .git, and it doesn't get created even if I run "git-pull" or
"git-pull origin pu".
I realize that I'm far behind in my understanding of GIT, but it seems
to me that something is wrong in the new layout.
We have a line that says: "pull from pu branch of origin and merge it
into local pu branch even if fast-forward is impossible". However,
there it no local pu branch. Yet not having this line blocks updating
of master branch.
It's like saying: I won't update master branch because there is another
branch that you are not tracking locally, but if you were, it would not
fast forward. Seems quite perverse to me.
My .git/config file is:
[core]
repositoryformatversion = 0
filemode = true
logallrefupdates = true
[remote "origin"]
url = git://www.kernel.org/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Junio C Hamano @ 2006-12-28 22:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexandre Julliard, Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.63.0612281710350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Thank you, everybody.
^ permalink raw reply
* Re: [PATCH] update hook: redirect _both_ diagnostic lines to stderr upon tag failure
From: Junio C Hamano @ 2006-12-28 22:14 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87tzzg6oyp.fsf@rho.meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Otherwise, sending the diagnostic to stdout would provoke a protocol failure.
Very true; thanks for the patch.
However, I suspect that we'd want to prevent this by redirecting
on the caller side, so that the hook writers do not have to
worry about the issue. I haven't looked at the code that runs
the hook for some time but we should be able to do that...
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Junio C Hamano @ 2006-12-28 22:44 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Shawn Pearce, Johannes Schindelin, Lars Hjemli
In-Reply-To: <1167341346.12660.17.camel@dv>
[jc: some people CC'ed because I'll talk about logallrefupdates
at the end]
Pavel Roskin <proski@gnu.org> writes:
> Actually, it's strange that I don't actually have refs/heads/pu
> under .git, and it doesn't get created even if I run "git-pull" or
> "git-pull origin pu".
"git-pull" without argument (and "git-pull origin") are affected
by the config (and .git/remotes/origin), so we will look at your
config later.
With "git-pull origin pu", you are saying "use URL for origin
but this time I am not interested in the set of branches to
fetch by default specified in my config". And single token "pu"
means you do not want to store the fetch result in any tracking
branch (otherwise you would explicitly say "pu:refs/heads/pu" or
"pu:/refs/remotes/origin/pu").
> We have a line that says: "pull from pu branch of origin and merge it
> into local pu branch even if fast-forward is impossible".
Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
If so, the line does _not_ say that. It does not talk about
pulling nor merging. What it says is "My refs/heads/pu is used
as a tracking branch for keeping track of the progress of his
'pu'; because I know he rewinds and rebases, please override the
fast-forward check when you store the updated value of his 'pu'
to my 'refs/heads/pu'".
> However,
> there it no local pu branch. Yet not having this line blocks updating
> of master branch.
Now that is worrisome. "git pull" and "git pull origin" (but
not "git pull pu" for the reason I mentioned earlier) should
create your "pu" branch if you have the configuration.
Let me understand the situation. Your config file is:
> My .git/config file is:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> logallrefupdates = true
> [remote "origin"]
> url = git://www.kernel.org/pub/scm/git/git.git
> fetch = refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
So you may not have refs/heads/pu (iow, you do not build on top
of my 'pu'), but the config says refs/remotes/origin/ is used to
track all my branches. Do you have refs/remotes/origin/pu?
If so, then "git fetch" would error out exactly because 'pu'
would not fast forward and the config says it does not allow
non-fast-forward fetch.
It might make sense to make the default configuration git
clone creates to say
[remote "origin"]
url = git://www.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/origin/*
instead.
I think I suggested this once but vaguely recall some people
objected, for the reason that an unusual situation such as
non-fast-forward should always error out for safety and should
require an explicit override by the user.
But come to think of it, I think failing to update the remote
tracking branch for non-fast-forward does not buy us very much.
Letting the user to be aware of the situation has value, but at
that point, I do not think there is much else the user can do.
The purpose of the tracking branches is to track what happens on
the remote side, and the user is in no position to override what
has already happend on the remote side (otherwise it stops being
"tracking branches"). If reflogs are enabled on remote tracking
braches, you can always get back the older state if you wanted
to.
That makes me notice another thing. We do not seem to create
reflog for remotes/ hierarchy even when logallrefupdates is set
to true. Would people object if we did this?
diff --git a/refs.c b/refs.c
index 8b2a3c1..e88ed8b 100644
--- a/refs.c
+++ b/refs.c
@@ -925,7 +925,8 @@ static int log_ref_write(struct ref_lock *lock,
const char *committer;
if (log_all_ref_updates &&
- !strncmp(lock->ref_name, "refs/heads/", 11)) {
+ (!strncmp(lock->ref_name, "refs/heads/", 11) ||
+ !strncmp(lock->ref_name, "refs/remotes/", 13))) {
if (safe_create_leading_directories(lock->log_file) < 0)
return error("unable to create directory for %s",
lock->log_file);
^ permalink raw reply related
* How to build manpages on OS X
From: Steven Grimm @ 2006-12-28 23:32 UTC (permalink / raw)
To: git
Didn't see this documented anywhere, so...
If you want to do a full build of git on OS X including the manpages,
you need the asciidoc and xmlto packages. Both of them are available
from macports.org (formerly known as DarwinPorts) but out of the box,
they don't work quite right. If you try doing a "make doc", you get the
following error from xmlto:
I/O error : Attempt to load network entity
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
The superficial reason for that error is that xmlto is calling the
xsltproc utility with a command-line option that tells it to not fetch
documents from the network. If you edit xmlto and remove that option,
the doc build will work, but it will have to fetch a bunch of files from
SourceForge for every manpage, which is dog slow.
The real solution is to use local copies of the files it's trying to
fetch. These files are installed as part of one of the dependencies when
you install xmlto, but the install process doesn't tell the system where
to look for them! To use these local copies, you need to do two things.
First, create an XML catalog file. Typically it's called catalog.xml.
The contents should be:
<?xml version='1.0'?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
<rewriteURI
uriStartString="http://docbook.sourceforge.net/release/xsl/current/"
rewritePrefix="file:///opt/local/share/xsl/docbook-xsl/" />
<rewriteURI uriStartString="http://www.oasis-open.org/docbook/xml/4.2/"
rewritePrefix="file:///opt/local/share/xml/docbook-xml/4.3/" />
</catalog>
Yes, that second rewriteURI maps the 4.2 docbook URI to the 4.3 version
-- blame the MacPorts packages, because that's what gets installed. The
mismatch doesn't appear to hurt anything. (If you're reading this from
the mailing list archive, MacPorts might have updated the packages since
I wrote this, so adjust the paths accordingly.)
Now you need to tell the system to use the file. You do that using the
XML_CATALOG_FILES environment variable, like so:
$ export XML_CATALOG_FILES=`pwd`/catalog.xml
$ make prefix=/opt/local doc
$ sudo make prefix=/opt/local install-doc
Annoying that it doesn't just work, but hopefully this will save someone
some Googling around.
-Steve
^ permalink raw reply
* Re: t9200-git-cvsexportcommit.sh failed on CYGWIN
From: SungHyun Nam @ 2006-12-28 23:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: GIT
In-Reply-To: <en0b47$bjm$3@sea.gmane.org>
Jakub Narebski wrote:
> [Cc: git@vger.kernel.org]
>
> SungHyun Nam wrote:
>
>> Below is the test messages.
>>
>> BTW, I hope I can define 'NO_CVS_TESTS' to skip this test.
> [...]
>> * ok 7: Update file with spaces in file name
>> * FAIL 8: File with non-ascii file name
>> mkdir -p
>
> What filesystem? Some filesystems are just broken...
NTFS (no FAT32 here).
Anyway, I test it step by step manually, and then...
$ cd tmp; mkdir t; cd t
$ ls -l
total 0
$ mkdir -p Å/goo
mkdir: cannot create directory `Å/goo': No such file or directory
$ ls -l
total 0
$ mkdir Å
mkdir: cannot create directory `Å': File exists
$ ls -l
total 0
I can create directory which contains Hangul (multibyte) characters.
$ mkdir ko_한글_lang
$ ls -l
total 0
drwxr-xr-x+ 2 namsh staff 0 Dec 29 08:41 ko_한글_lang/
Does it depend on Windows version? I use Korean version of Windows Home
Edition. I also test it with 'CYGWIN=codepage:ansi' without luck.
Thanks,
namsh
^ permalink raw reply
* Re: How to build manpages on OS X
From: Junio C Hamano @ 2006-12-29 0:24 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <459453F8.1010200@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> The real solution is to use local copies of the files it's trying to
> fetch. These files are installed as part of one of the dependencies
> when you install xmlto, but the install process doesn't tell the
> system where to look for them! To use these local copies, you need to
> do two things.
Sounds like a DarwinPorts bug (or lack of feature, or maybe
feature still being added but not given to the public, I dunno).
My understanding is that these catalogs are maintained
automatically by the distribution when stylesheets are
installed. For example, on Debian systems, xml-core seems to
offer the infrastructure and .postinst scripts for packages such
as docbook-xsl use update-xmlcatalog tool to make sure the
stylesheets they install are found locally on the system.
In any case, thanks for the write-up.
> Annoying that it doesn't just work, but hopefully this will save
> someone some Googling around.
I've added a pointer to your message at gmane archive on Gitwiki
page (GitDocumentation).
^ permalink raw reply
* [PATCH 1/2] core.logallrefupdates: log remotes/ tracking branches.
From: Junio C Hamano @ 2006-12-29 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm97tzbt.fsf@assigned-by-dhcp.cox.net>
Not using reflog for tags/ was very sensible; not giving reflog
for the remotes/ was not.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
refs.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 8b2a3c1..e88ed8b 100644
--- a/refs.c
+++ b/refs.c
@@ -925,7 +925,8 @@ static int log_ref_write(struct ref_lock *lock,
const char *committer;
if (log_all_ref_updates &&
- !strncmp(lock->ref_name, "refs/heads/", 11)) {
+ (!strncmp(lock->ref_name, "refs/heads/", 11) ||
+ !strncmp(lock->ref_name, "refs/remotes/", 13))) {
if (safe_create_leading_directories(lock->log_file) < 0)
return error("unable to create directory for %s",
lock->log_file);
--
1.5.0.rc0.gf5c587
^ permalink raw reply related
* [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone
From: Junio C Hamano @ 2006-12-29 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vzm97tzbt.fsf@assigned-by-dhcp.cox.net>
This changes the default remote.origin.fetch configuration
created by git-clone so that it allows non-fast-forward updates.
When using the separate-remote layout with reflog enabled, it
does not make much sense to refuse to update the remote tracking
branch just because some of them do not fast-forward. git-fetch
issues warnings on non-fast-forwardness, and the user can peek
at what the previous state was using the reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index f37eb9d..3d388de 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -388,7 +388,7 @@ then
# Set up the mappings to track the remote branches.
git-repo-config remote."$origin".fetch \
- "refs/heads/*:$remote_top/*" '^$' &&
+ "+refs/heads/*:$remote_top/*" '^$' &&
rm -f "refs/remotes/$origin/HEAD"
git-symbolic-ref "refs/remotes/$origin/HEAD" \
"refs/remotes/$origin/$head_points_at" &&
--
1.5.0.rc0.gf5c587
^ permalink raw reply related
* [PATCH/RFT] Work around http-fetch built with cURL 7.16.0
From: Junio C Hamano @ 2006-12-29 0:40 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xgt57wu.fsf@assigned-by-dhcp.cox.net>
It appears that curl_easy_duphandle() from libcurl 7.16.0
returns a curl session handle which fails GOOD_MULTI_HANDLE()
check in curl_multi_add_handle(). This causes fetch_ref() to
fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I think people who were having trouble with cURL 7.16.0 want
to have the issue resolved before v1.5.0-rc1. Please test
and report, or else ;-).
http.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http.h b/http.h
index 6e12e41..324fcf4 100644
--- a/http.h
+++ b/http.h
@@ -18,7 +18,7 @@
#define curl_global_init(a) do { /* nothing */ } while(0)
#endif
-#if LIBCURL_VERSION_NUM < 0x070c04
+#if (LIBCURL_VERSION_NUM < 0x070c04) || (LIBCURL_VERSION_NUM == 0x071000)
#define NO_CURL_EASY_DUPHANDLE
#endif
--
1.5.0.rc0.gf5c587
^ permalink raw reply related
* Re: branch.pu.forcefetch
From: Pavel Roskin @ 2006-12-29 1:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce, Johannes Schindelin, Lars Hjemli
In-Reply-To: <7vzm97tzbt.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-12-28 at 14:44 -0800, Junio C Hamano wrote:
> [jc: some people CC'ed because I'll talk about logallrefupdates
> at the end]
OK.
> Pavel Roskin <proski@gnu.org> writes:
>
> > Actually, it's strange that I don't actually have refs/heads/pu
> > under .git, and it doesn't get created even if I run "git-pull" or
> > "git-pull origin pu".
>
> "git-pull" without argument (and "git-pull origin") are affected
> by the config (and .git/remotes/origin), so we will look at your
> config later.
>
> With "git-pull origin pu", you are saying "use URL for origin
> but this time I am not interested in the set of branches to
> fetch by default specified in my config". And single token "pu"
> means you do not want to store the fetch result in any tracking
> branch (otherwise you would explicitly say "pu:refs/heads/pu" or
> "pu:/refs/remotes/origin/pu").
OK, I'm going to take a "bird's view" of it. If you happen to think I'm
saying stupid things, it's just because I'm playing an even less
experienced user than I am.
I don't think it's a good idea to expose the layout under .git to the
end user. I do realize that git is just "plumbing", but things like
"refs/heads/" should probably be hidden from the user in any case.
Using path as an indicator that something should be saved looks like a
kludge.
Maybe we could have a notation for branches on remotes (e.g. pu@origin
or origin#pu), tracking branches and non-tracking branches? I would be
happy if the same name could be used for all of them. After all, that's
the way CVS and Subversion do it, and it's fine for most users. As for
the locations under refs, let's leave it to git.
> > We have a line that says: "pull from pu branch of origin and merge it
> > into local pu branch even if fast-forward is impossible".
>
> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
Yes, I'm talking about that line. And I don't like that I have to use a
magic token "refs/heads/pu" that doesn't correspond to a real file to
make it possible to keep git up-to-date.
[skip]
> > However,
> > there it no local pu branch. Yet not having this line blocks updating
> > of master branch.
>
> Now that is worrisome. "git pull" and "git pull origin" (but
> not "git pull pu" for the reason I mentioned earlier) should
> create your "pu" branch if you have the configuration.
>
> Let me understand the situation. Your config file is:
>
> > My .git/config file is:
> >
> > [core]
> > repositoryformatversion = 0
> > filemode = true
> > logallrefupdates = true
> > [remote "origin"]
> > url = git://www.kernel.org/pub/scm/git/git.git
> > fetch = refs/heads/*:refs/remotes/origin/*
> > [branch "master"]
> > remote = origin
> > merge = refs/heads/master
>
> So you may not have refs/heads/pu (iow, you do not build on top
> of my 'pu'), but the config says refs/remotes/origin/ is used to
> track all my branches. Do you have refs/remotes/origin/pu?
Yes. I'm doing a clean checkout now with the current git from the
"master" branch:
[proski@dv git]$ git-clone git://www.kernel.org/pub/scm/git/git.git
Initialized empty Git repository in /home/proski/tmp/git/git/.git/
remote: Generating pack...
remote: Done counting 35273 objects.
remote: Deltifying 35273 objects.
remote: 100% (35273/35273) done
Indexing 35273 objects.
remote: Total 35273, written 35273 (delta 24484), reused 35217 (delta 24444)
100% (35273/35273) done
Resolving 24484 deltas.
100% (24484/24484) done
Checking files out...
100% (761/761) done
[proski@dv git]$ git --version
git version 1.5.0.rc0.g4a4d
[proski@dv git]$ ls git/.git/refs/remotes/origin/
HEAD html maint man master next pu todo
[proski@dv git]$ ls git/.git/refs/heads/
master
[proski@dv git]$ cd git/
[proski@dv git]$ git-pull
Already up-to-date.
[proski@dv git]$ ls .git/refs/heads/
master
[proski@dv git]$
> If so, then "git fetch" would error out exactly because 'pu'
> would not fast forward and the config says it does not allow
> non-fast-forward fetch.
>
> It might make sense to make the default configuration git
> clone creates to say
>
> [remote "origin"]
> url = git://www.kernel.org/pub/scm/git/git.git
> fetch = +refs/heads/*:refs/remotes/origin/*
>
> instead.
>
> I think I suggested this once but vaguely recall some people
> objected, for the reason that an unusual situation such as
> non-fast-forward should always error out for safety and should
> require an explicit override by the user.
In this particular case of the GIT project, it's very rare that I would
be interested in the "pu" branch. I'm mostly interested in "master",
and I can be occasionally interested in "next".
The default for git-clone is to clone all branches. It's OK for me
because I'm on a fast connection (I hear angry voices of modem users).
Actually, I don't see an option to git-clone to clone HEAD or selected
branches only. The "-o" option seems to be something different, even
though the manual mention branches.
Unfortunately, updating the current branch fails because pu is not
fast-forwarding. Why fail if I'm not even on pu?
In other words, the basic default functionality is hampered because of a
branch the user is not even using in any way. And the fix involves
editing the config file.
> But come to think of it, I think failing to update the remote
> tracking branch for non-fast-forward does not buy us very much.
> Letting the user to be aware of the situation has value, but at
> that point, I do not think there is much else the user can do.
> The purpose of the tracking branches is to track what happens on
> the remote side, and the user is in no position to override what
> has already happend on the remote side (otherwise it stops being
> "tracking branches"). If reflogs are enabled on remote tracking
> braches, you can always get back the older state if you wanted
> to.
I tend to agree. Of course, if any porcelains require or prefer
fast-forward, they should be able to prevent non-fast-forward updates.
Perhaps they would be OK with non-fast-forward updates on branches other
than those they are specifically managing?
> That makes me notice another thing. We do not seem to create
> reflog for remotes/ hierarchy even when logallrefupdates is set
> to true. Would people object if we did this?
No objection on my part.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [BUG] git-fetch -k is broken
From: Nicolas Pitre @ 2006-12-29 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd574iqa0.fsf@assigned-by-dhcp.cox.net>
[ resuming an old thread ]
On Thu, 30 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Actually, the .keep file is simply not removed as it should.
> >
> > But first it appears that commit f64d7fd2 added an && on line 431 of
> > git-fetch.sh and that cannot be right. There is simply no condition for
> > not removing the lock file. It must be removed regardless if the
> > previous command succeeded or not. Junio?
>
> True, but your "echo" patch breaks things even more -- when fast
> forward check fails, it should cause the entire command should
> report that with the exit status.
This "echo" patch was not a fix. It was only an expeditive hack to
demonstrate the problem. Please consider this stripped down test case
instead:
-------- >8
#!/bin/sh
#
LF='
'
IFS="$LF"
( : subshell because we muck with IFS
pack_lockfile=
IFS=" $LF"
(
echo "keep 123456789abcdef0123456789abcdef012345678"
) |
while read sha1 remote_name
do
case "$sha1" in
# special line coming from index-pack with the pack name
keep)
pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
echo "pack_lockfile set to $pack_lockfile"
continue ;;
esac
done &&
if [ "$pack_lockfile" ]; then echo "rm -f $pack_lockfile"; fi
echo "pack_lockfile=$pack_lockfile"
)
-------- >8
The output I get is:
pack_lockfile set to /pack/pack-123456789abcdef0123456789abcdef012345678.keep
pack_lockfile=
In other words the line with the echo "rm -f ..." never shows up and I
don't know why.
> That suggests that we need to come up with a way to clean up
> these .keep files some other way than just being one of the
> command near the end. As to the mysterious "echo e <empty>"
> I will not have chance to look at it myself until later today
> (I'm at work now and it is not my git day today).
I hope you (or anyone else) will be able to have a look at this. My
shell programming skills are simply not up to it.
Nicolas
^ permalink raw reply
* Re: t9200-git-cvsexportcommit.sh failed on CYGWIN
From: Junio C Hamano @ 2006-12-29 1:58 UTC (permalink / raw)
To: SungHyun Nam; +Cc: git, Jakub Narebski
In-Reply-To: <4594565B.3090804@gmail.com>
SungHyun Nam <goweol@gmail.com> writes:
> Jakub Narebski wrote:
> ...
>> What filesystem? Some filesystems are just broken...
>
> NTFS (no FAT32 here).
> ...
> $ mkdir -p Å/goo
> mkdir: cannot create directory `Å/goo': No such file or directory
SungHyun Nam <goweol@gmail.com> writes:
> Jakub Narebski wrote:
>> SungHyun Nam wrote:
>>
>>> Below is the test messages.
>>>
>>> BTW, I hope I can define 'NO_CVS_TESTS' to skip this test.
>> ...
>> What filesystem? Some filesystems are just broken...
>
> NTFS (no FAT32 here).
>
> Anyway, I test it step by step manually, and then...
>
> $ cd tmp; mkdir t; cd t
> $ ls -l
> total 0
> $ mkdir -p Å/goo
> mkdir: cannot create directory `Å/goo': No such file or directory
Some filesystems cannot use arbitrary sequence of non NUL bytes
as pathnames.
It would be handy to have a way to skip tests that the user
knows would not pass on his particular system.
I do not think that such a request should be named NO_CVS_TESTS,
though. It is not like NO_SVN_TESTS where your system does not
have svn installed. I think even on hanglized NTFS, CVS
operations on pathnames that use only portable pathname
characters should work.
I am considering doing this instead...
-- >8 --
GIT_SKIP_TESTS: allow users to omit tests that are know to break
In some environments, certain tests have no way of succeeding
due to platform limitation, such as lack of 'unzip' program, or
filesystem that do not allow arbitrary sequence of non-NUL bytes
as pathnames.
You should be able to say something like
$ cd t
$ GIT_SKIP_TESTS=t9200.8 t9200-git-cvsexport-commit.sh
and even:
$ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make test
to omit such tests. The value of the environment variable is a
SP separated list of patterns that tells which tests to skip,
and either can match the "t[0-9]{4}" part to skip the whole
test, or t[0-9]{4} followed by ".$number" to say which
particular test to skip.
Note that some tests in the existing test suite rely on previous
test item, so you cannot arbitrarily disable one and expect the
remainder of test to check what the test originally was intended
to check.
---
diff --git a/t/test-lib.sh b/t/test-lib.sh
index ad2b6f6..98f69d8 100755
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -125,16 +125,43 @@ test_run_ () {
return 0
}
+test_skip () {
+ this_test=$(expr "./$0" : '.*/\(t[0-9]*\)-[^/]*$')
+ this_test="$this_test.$(expr "$test_count" + 1)"
+ to_skip=
+ for skp in $GIT_SKIP_TESTS
+ do
+ case "$this_test" in
+ $skp)
+ to_skip=t
+ esac
+ done
+ case "$to_skip" in
+ t)
+ say >&3 "skipping test: $@"
+ test_count=$(expr "$test_count" + 1)
+ say "skip $test_count: $1"
+ : true
+ ;;
+ *)
+ false
+ ;;
+ esac
+}
+
test_expect_failure () {
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-failure"
- say >&3 "expecting failure: $2"
- test_run_ "$2"
- if [ "$?" = 0 -a "$eval_ret" != 0 -a "$eval_ret" -lt 129 ]
+ if ! test_skip "$@"
then
- test_ok_ "$1"
- else
- test_failure_ "$@"
+ say >&3 "expecting failure: $2"
+ test_run_ "$2"
+ if [ "$?" = 0 -a "$eval_ret" != 0 -a "$eval_ret" -lt 129 ]
+ then
+ test_ok_ "$1"
+ else
+ test_failure_ "$@"
+ fi
fi
echo >&3 ""
}
@@ -142,13 +169,16 @@ test_expect_failure () {
test_expect_success () {
test "$#" = 2 ||
error "bug in the test script: not 2 parameters to test-expect-success"
- say >&3 "expecting success: $2"
- test_run_ "$2"
- if [ "$?" = 0 -a "$eval_ret" = 0 ]
+ if ! test_skip "$@"
then
- test_ok_ "$1"
- else
- test_failure_ "$@"
+ say >&3 "expecting success: $2"
+ test_run_ "$2"
+ if [ "$?" = 0 -a "$eval_ret" = 0 ]
+ then
+ test_ok_ "$1"
+ else
+ test_failure_ "$@"
+ fi
fi
echo >&3 ""
}
@@ -156,13 +186,16 @@ test_expect_success () {
test_expect_code () {
test "$#" = 3 ||
error "bug in the test script: not 3 parameters to test-expect-code"
- say >&3 "expecting exit code $1: $3"
- test_run_ "$3"
- if [ "$?" = 0 -a "$eval_ret" = "$1" ]
+ if ! test_skip "$@"
then
- test_ok_ "$2"
- else
- test_failure_ "$@"
+ say >&3 "expecting exit code $1: $3"
+ test_run_ "$3"
+ if [ "$?" = 0 -a "$eval_ret" = "$1" ]
+ then
+ test_ok_ "$2"
+ else
+ test_failure_ "$@"
+ fi
fi
echo >&3 ""
}
@@ -223,3 +256,22 @@ test=trash
rm -fr "$test"
test_create_repo $test
cd "$test"
+
+this_test=$(expr "./$0" : '.*/\(t[0-9]*\)-[^/]*$')
+for skp in $GIT_SKIP_TESTS
+do
+ to_skip=
+ for skp in $GIT_SKIP_TESTS
+ do
+ case "$this_test" in
+ $skp)
+ to_skip=t
+ esac
+ done
+ case "$to_skip" in
+ t)
+ say >&3 "skipping test $this_test altogether"
+ say "skip all tests in $this_test"
+ test_done
+ esac
+done
^ permalink raw reply related
* Re: [BUG] git-fetch -k is broken
From: Junio C Hamano @ 2006-12-29 2:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0612282031390.18171@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> [ resuming an old thread ]
>
> On Thu, 30 Nov 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > Actually, the .keep file is simply not removed as it should.
>> >
>> > But first it appears that commit f64d7fd2 added an && on line 431 of
>> > git-fetch.sh and that cannot be right. There is simply no condition for
>> > not removing the lock file. It must be removed regardless if the
>> > previous command succeeded or not. Junio?
>>
>> True, but your "echo" patch breaks things even more -- when fast
>> forward check fails, it should cause the entire command should
>> report that with the exit status.
>
> This "echo" patch was not a fix. It was only an expeditive hack to
> demonstrate the problem. Please consider this stripped down test case
> instead:
>
> -------- >8
> #!/bin/sh
> #
>
> LF='
> '
> IFS="$LF"
>
> ( : subshell because we muck with IFS
> pack_lockfile=
> IFS=" $LF"
> (
> echo "keep 123456789abcdef0123456789abcdef012345678"
> ) |
> while read sha1 remote_name
> do
> case "$sha1" in
> # special line coming from index-pack with the pack name
> keep)
> pack_lockfile="$GIT_OBJECT_DIRECTORY/pack/pack-$remote_name.keep"
> echo "pack_lockfile set to $pack_lockfile"
> continue ;;
> esac
> done &&
> if [ "$pack_lockfile" ]; then echo "rm -f $pack_lockfile"; fi
> echo "pack_lockfile=$pack_lockfile"
> )
> -------- >8
>
> The output I get is:
>
> pack_lockfile set to /pack/pack-123456789abcdef0123456789abcdef012345678.keep
> pack_lockfile=
>
> In other words the line with the echo "rm -f ..." never shows up and I
> don't know why.
The whole while loop is run in a subshell and the process runs
the last echo "pack_lockfile=$pack_lockfile" is a process
different from the one that did the other echo in the while
loop.
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Junio C Hamano @ 2006-12-29 2:30 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1167355326.15189.34.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
>> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
>
> Yes, I'm talking about that line. And I don't like that I have to use a
> magic token "refs/heads/pu" that doesn't correspond to a real file to
> make it possible to keep git up-to-date.
I think we misunderstood each other. That line is inconsistent
with what your config has, which is the separate-remote layout,
which I did not know you were using. In separate-remote layout,
you don't have refs/heads/pu so if we do not do the patches you
are agreeing to, you would want to have something like:
[remote "origin"]
fetch = +refs/heads/pu:refs/remotes/origin/pu
fetch = refs/heads/*:refs/remotes/origin/*
In other words, "path does not correspond to a real file"
problem does not exist. If you tell git to track 'pu' at
refs/remotes/origin/pu, it will use that path -- so that path
has a corresponding real file.
> Unfortunately, updating the current branch fails because pu is not
> fast-forwarding. Why fail if I'm not even on pu?
Your being not on 'pu' does not have anything to do with it. In
fact, you do not even want to be _on_ any of your tracking
branches. In the separate-remote layout, you cannot even be on
remotes/origin/pu branch.
What you are seeing is fetch's safety feature that stops and
notifies you the situation when the remote rewinds/rebases the
branch you are tracking with tracking branches. We have had it
turned on by default for a long time, and you have it turned on
in your config because that is the default. If you do not want
to use that feature (and for git.git, you certainly don't), just
turn it off. When you know you do not want to use a feature,
you do not have to.
Turning it off by default was not a wise thing to do in general
for a long time, because rewound/rebased tip loses information,
and we did not have reflog enabled by default. Your message
raised this issue to attention of the list, and I suggested two
patches out of it, both of which I think are sane things to do.
If the list agrees, we can turn it off by default now.
^ permalink raw reply
* Re: read-for-fill and caching in gitweb (Re: kernel.org mirroring)
From: Robert Fitzsimons @ 2006-12-29 3:21 UTC (permalink / raw)
To: Martin Langhoff
Cc: Linus Torvalds, Jeff Garzik, H. Peter Anvin, Rogan Dawes,
Kernel Org Admin, Git Mailing List, Jakub Narebski
In-Reply-To: <46a038f90612281245s52bdd868h8c421951c7abeb84@mail.gmail.com>
> I will probably try to implement caching for the
> projects, summary & log/shortlog pages using Cache::FastMap
Here are the mean (and standard deviation) in milliseconds for those
pages using a few different versions of gitweb.
project_list summary shortlog log
v267 173 1.6 1141 8.8 795 5.0 919 1.9
1.4.4.3 220 2.3 397 2.4 930 4.2 1113 56.9
1.5.0.rc0.g4a4d 226 1.9 292 1.7 352 4.0 491 6.7
1.5.0.rc0.g4a4d 60 1.0 131 0.7 195 1.2 347 3.7
(mod_perl)
I think there would be a benefit in deploying a more recent version of
gitweb on kernel.org and and even bigger benefit if it use mod_perl. I
would be happy to help, if I can.
I'll look into the increase in time for the project_list in more recent
versions of gitweb, tomorrow.
Robert
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Pavel Roskin @ 2006-12-29 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xgrsabr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-12-28 at 18:30 -0800, Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
>
> >> Are you talking about "remote.origin.fetch = +pu:refs/heads/pu"?
> >
> > Yes, I'm talking about that line. And I don't like that I have to use a
> > magic token "refs/heads/pu" that doesn't correspond to a real file to
> > make it possible to keep git up-to-date.
>
> I think we misunderstood each other.
I just didn't notice that your question used a different line. I was
talking about
fetch = +refs/heads/pu:refs/remotes/origin/pu
> That line is inconsistent
> with what your config has, which is the separate-remote layout,
> which I did not know you were using. In separate-remote layout,
> you don't have refs/heads/pu so if we do not do the patches you
> are agreeing to, you would want to have something like:
>
> [remote "origin"]
> fetch = +refs/heads/pu:refs/remotes/origin/pu
> fetch = refs/heads/*:refs/remotes/origin/*
I get it now. "refs/heads/pu" must be the path on the remote side.
The whole thing remains pretty hairy for my taste, but it looks like we
are going to untangle it step-by-step.
> Turning it off by default was not a wise thing to do in general
> for a long time, because rewound/rebased tip loses information,
> and we did not have reflog enabled by default. Your message
> raised this issue to attention of the list, and I suggested two
> patches out of it, both of which I think are sane things to do.
> If the list agrees, we can turn it off by default now.
Just a random idea - if fast-forward fails, save the original head
somewhere under refs as a backup. It's like "patch" saving *.orig files
if there is any doubt that the patch was applied cleanly.
But I'm fine with reflog too.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] xdl_merge(): fix a segmentation fault when refining conflicts
From: Shawn Pearce @ 2006-12-29 4:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alexandre Julliard, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0612281710350.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Thank you Alexandre! I looked for the bug for quite some time, but
> was never close to the real culprit.
Thanks for fixing this!
> +<<<<<<< orig.txt
> +=======
> +Nam et si ambulavero in medio umbrae mortis,
> +non timebo mala, quoniam TU mecum es:
> +virga tua et baculus tuus ipsa me consolata sunt.
> +>>>>>>> new5.txt
As a side note I lately have noticed that xdl_merge is producing a
conflict like the above when one branch added the lower half and
the other branch didn't change anything in the area.
I haven't spent any time to try to reproduce it, or to see if RCS'
merge utility would automatically merge the file without producing
a conflict. But right now it does seem like xdl_merge is producing
conflicts when I didn't think it should be.
--
Shawn.
^ permalink raw reply
* Re: branch.pu.forcefetch
From: Shawn Pearce @ 2006-12-29 4:31 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Junio C Hamano, git
In-Reply-To: <1167363263.15189.79.camel@dv>
Pavel Roskin <proski@gnu.org> wrote:
> Just a random idea - if fast-forward fails, save the original head
> somewhere under refs as a backup. It's like "patch" saving *.orig files
> if there is any doubt that the patch was applied cleanly.
That's the entire point of the reflog. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] Allow non-fast-forward of remote tracking branches in default clone
From: Shawn Pearce @ 2006-12-29 4:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk60btucu.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> This changes the default remote.origin.fetch configuration
> created by git-clone so that it allows non-fast-forward updates.
Ack'd, but only if '[PATCH 1/2] core.logallrefupdates: log remotes/
tracking branches.' is also applied.
I think both are worth applying.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/11] Misc. pull/merge/am improvements
From: Shawn Pearce @ 2006-12-29 4:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzzguvrp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> While I was looking at the problem, I noticed something a bit
> easier to reproduce and should be lot easier to diagnose. At
> http://userweb.kernel.org/~junio/broken.tar, I have a tarball of
> git.git repository.
Thanks. I downloaded that tar but I can't debug it right now.
I'm feeling under the weather and already had a long day; I'm too
fried to seriously look at this pack code. I'll do it tomorrow
evening.
--
Shawn.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2006-12-29 5:44 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b73gx43.fsf@assigned-by-dhcp.cox.net>
I've merged a handful topics since v1.5.0-rc0.
- reflog is now integral part of the data tracked by git, as
far as local repository is concerned. You do not have to end
your sentence with "... but only if you haven't pruned" when
you tell your users "don't worry, you can get it back with
master@{2.hours.ago}" anymore.
- a single command "git gc" would help your repository
housekeeping chores.
- shallow-clone capable upload-pack/fetch-pack pair is in.
Although I think the way they cauterize the ancestry graph
during the want-have exchange is basically sound, I haven't
used it extensively and suspect not many people have. The
additional code, however, does not seem to harm the normal,
non-shallow operation in any way; this is to give them wider
exposure.
- recording the commit encoding in the new "encoding" header
and using it together with i18n.{logoutput,commit}encoding
upon output is also in. I think Nico's suggestion to use
LANG also makes sense (perhaps with LC_CTYPE), but haven't
done that myself yet.
- git-svn got a handful improvements.
- segfaulting bug in xdl_merge was fixed.
I'm waiting for ack's to my workaround for http-fetch breakage
when built with cURL 7.16.0, which I would like to resolve
before v1.5.0-rc1. Also I have a reproducible problem which I
suspect is with Shawn's sliding mmap(), and am hoping we can
ship the sliding mmap() as part of the v1.5.0 after resolving
it.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alexandre Julliard (6):
Shallow clone: do not ignore shallowness when following tags
fetch-pack: Properly remove the shallow file when it becomes empty.
upload-pack: Check for NOT_SHALLOW flag before sending a shallow to
the client.
git-fetch: Reset shallow_depth before auto-following tags.
get_shallow_commits: Avoid memory leak if a commit has been reached
already.
fetch-pack: Do not fetch tags for shallow clones.
Andy Parkins (1):
hooks/commit-msg: add example to add Signed-off-by line to message
Eric Wong (9):
git-svn: quiet down tests and fix some unportable shell constructs
git-svn: dcommit should diff against the current HEAD after committing
t6024-recursive-merge: quiet down this test
test-lib: quiet down init-db output for tests
t9200-git-cvsexportcommit.sh: quiet down commit
git-svn: remove non-delta fetch code paths
git-svn: print out the SVN library version in --version, too
git-svn: verify_ref() should actually --verify
git-svn: sort multi-init output
Jakub Narebski (2):
gitweb: Add mod_perl version string to "generator" meta header
gitweb: Precompile CGI routines for mod_perl
Jim Meyering (1):
update hook: redirect _both_ diagnostic lines to stderr upon tag failure
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
xdl_merge(): fix a segmentation fault when refining conflicts
Junio C Hamano (32):
We should make sure that the protocol is still extensible.
Why does it mean we do not have to register shallow if we have one?
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
shallow clone: unparse and reparse an unshallowed commit
add for_each_reflog_ent() iterator
Protect commits recorded in reflog from pruning.
Teach git-repack to preserve objects referred to by reflog entries.
reflog: fix warning message.
Move in_merge_bases() to commit.c
git reflog expire
reflog expire: prune commits that are not incomplete
reflog expire: do not punt on tags that point at non commits.
show-branch --reflog: add documentation.
Document --numstat in git-apply and git-diff
Document git-reset <commit> -- <paths>...
Move encoding conversion routine out of mailinfo to utf8.c
i18n.logToUTF8: convert commit log message to UTF-8
Teach log family --encoding
everyday: update for v1.5.0
count-objects -v: show number of packs as well.
rerere gc: honor configuration and document it
git-reflog: gc.* configuration and documentation.
everyday: replace a few 'prune' and 'repack' with 'gc'
Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc
Set NO_MMAP for Cygwin by default
UTF-8: introduce i18n.logoutputencoding.
gcc does not necessarily pass runtime libpath with -R
Rename t3900 test vector file
t3900: test conversion to non UTF-8 as well
GIT_SKIP_TESTS: allow users to omit tests that are known to break
core.logallrefupdates: log remotes/ tracking branches.
Allow non-fast-forward of remote tracking branches in default clone
Nicolas Pitre (3):
add .mailmap for git-shortlog output with the git repository
Add git-reflog to .gitignore
move git-blame to its place in .gitignore
Quy Tonthat (1):
git-send-email: default value for "From:" field.
Robert Fitzsimons (1):
gitweb: Re-enable rev-list --parents for parse_commit.
Shawn O. Pearce (8):
Don't crash during repack of a reflog with pruned commits.
Create 'git gc' to perform common maintenance operations.
Use GIT_REFLOG_ACTION environment variable instead.
Honor GIT_REFLOG_ACTION in git-rebase.
Use branch names in 'git-rebase -m' conflict hunks.
Ensure `git-pull` fails if `git-merge` fails.
Honor pull.{twohead,octopus} in git-merge.
Allow git-merge to select the default strategy.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-29 5:44 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* sp/merge (Thu Dec 28 02:35:34 2006 -0500) 5 commits
- Improve merge performance by avoiding in-index merges.
- Avoid git-fetch in `git-pull .` when possible.
+ Use merge-recursive in git-am -3.
+ Allow merging bare trees in merge-recursive.
+ Move better_branch_name above get_ref in merge-recursive.
Good intentions, very attractive, somewhat disruptive and might
be risky breaking existing users. I'd like at least the earlier
parts to be in v1.5.0-rc1.
* jc/curl (Wed Dec 27 13:59:26 2006 -0800) 1 commit
+ Work around http-fetch built with cURL 7.16.0
Waiting for an Ack.
* sp/mmap (Wed Dec 27 02:46:23 2006 -0500) 22 commits
- Fix random segfaults in pack-objects.
- Cleanup read_cache_from error handling.
- Replace mmap with xmmap, better handling MAP_FAILED.
- Release pack windows before reporting out of memory.
- Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
- Test suite for sliding window mmap implementation.
- Create pack_report() as a debugging aid.
- Support unmapping windows on 'temporary' packfiles.
- Improve error message when packfile mmap fails.
- Ensure core.packedGitWindowSize cannot be less than 2 pages.
- Load core configuration in git-verify-pack.
- Fully activate the sliding window pack access.
- Unmap individual windows rather than entire files.
- Document why header parsing won't exceed a window.
- Loop over pack_windows when inflating/accessing data.
- Replace use_packed_git with window cursors.
- Refactor how we open pack files to prepare for multiple windows.
- Create read_or_die utility routine.
- Use off_t for index and pack file lengths.
- Refactor packed_git to prepare for sliding mmap windows.
- Introduce new config option for mmap limit.
- Replace unpack_entry_gently with unpack_entry.
Known breakage exists that this series is highly suspected.
Will diagnose and merge to 'next' after fixing.
* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700) 1 commit
+ git-diff/git-apply: make diff output a bit friendlier to GNU patch
(part 2)
I promised this to wait until February. Most likely to be in
v1.5.1.
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
* jc/explain (Mon Dec 4 19:35:04 2006 -0800) 1 commit
- git-explain
* jc/3way (Wed Nov 29 18:53:13 2006 -0800) 1 commit
+ git-merge: preserve and merge local changes when doing fast
forward
* jc/web (Wed Nov 8 14:54:09 2006 -0800) 1 commit
- gitweb: steal loadavg throttle from kernel.org
* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800) 1 commit
- blame: --show-stats for easier optimization work.
These are on hold or will not be merged ever.
^ permalink raw reply
* Re: How to build manpages on OS X
From: Randal L. Schwartz @ 2006-12-29 6:02 UTC (permalink / raw)
To: Steven Grimm; +Cc: git
In-Reply-To: <459453F8.1010200@midwinter.com>
>>>>> "Steven" == Steven Grimm <koreth@midwinter.com> writes:
Steven> Didn't see this documented anywhere, so...
Steven> If you want to do a full build of git on OS X including the manpages, you need
Steven> the asciidoc and xmlto packages. Both of them are available from macports.org
Steven> (formerly known as DarwinPorts) but out of the box, they don't work quite
Steven> right.
I'm using the ones out of fink, and it seems to work just fine.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
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