* [PATCH jh/cvs-helper 1/2] Makefile: write NO_PYTHON setting to GIT-BUILD-OPTIONS file
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan, Brandon Casey
In-Reply-To: <Rxz2NOwzg1UZ0TgAtOhrA7e8wE02XwcSzNC9cc1EL_W_oN1BjtZn8ClmG5zKB_DKmTgVP0PlMYI@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The GIT-BUILD-OPTIONS file is sourced by the t/test-lib.sh script which
prepares the environment for the test suite. It is used to communicate
the user's settings for things like SHELL_PATH, TAR, NO_CURL, and NO_PERL.
Add NO_PYTHON so this setting will be available to the test suite.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 128c308..5c1ae7b 100644
--- a/Makefile
+++ b/Makefile
@@ -1615,6 +1615,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
+ @echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
--
1.6.4
^ permalink raw reply related
* [PATCH jh/cvs-helper 0/2] Fix building when python is not available
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan
These two are built on top of pu. I'm pretty sure jh/cvs-helper is
the relevant branch.
Brandon Casey (2):
Makefile: write NO_PYTHON setting to GIT-BUILD-OPTIONS file
t/test-lib.sh: don't perform python preparations when NO_PYTHON is
set
Makefile | 1 +
t/test-lib.sh | 18 +++++++++---------
2 files changed, 10 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH jh/cvs-helper 2/2] t/test-lib.sh: don't perform python preparations when NO_PYTHON is set
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan, Brandon Casey
In-Reply-To: <Rxz2NOwzg1UZ0TgAtOhrA7dGx1obNszSQLoUJ4IoUGJk5ekFKeKU4vpg535nyOx20P_IWNiudJo@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
When setting GITPYTHONLIB, a check is performed to test whether the path
that GITPYTHONLIB is set to is a valid directory. This test always fails
when NO_PYTHON is set since git_remote_cvs is not built. So add a test
on NO_PYTHON to the conditional that protects this section.
Additionally, move this section down so it is done _after_
GIT-BUILD-OPTIONS is sourced, so that the NO_PYTHON setting is available.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a7fbfef..d95c66b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -638,15 +638,6 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
-if test -z "$GIT_TEST_INSTALLED"
-then
- GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
- export GITPYTHONLIB
- test -d ../git_remote_cvs/build || {
- error "You haven't built git_remote_cvs yet, have you?"
- }
-fi
-
if ! test -x ../test-chmtime; then
echo >&2 'You need to build test-chmtime:'
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
@@ -655,6 +646,15 @@ fi
. ../GIT-BUILD-OPTIONS
+if test -z "$NO_PYTHON" -a -z "$GIT_TEST_INSTALLED"
+then
+ GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
+ export GITPYTHONLIB
+ test -d ../git_remote_cvs/build || {
+ error "You haven't built git_remote_cvs yet, have you?"
+ }
+fi
+
# Test repository
test="trash directory.$(basename "$0" .sh)"
test -n "$root" && test="$root/$test"
--
1.6.4
^ permalink raw reply related
* Re: Question regarding git fetch
From: Eric Raible @ 2009-08-27 16:21 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
> Git currently promises that your refs/remotes/* branches will
> never be updated unless you explicitly request it, even if you're
> fetching, merging, and pulling other stuff.
So your claim is that "git fetch central" is somehow more
explicit than "git fetch central master"?
I understand that "git fetch central" will use
remote.central.fetch (which _is_ explicit), but
the command itself is certainly _less_ explicit about
specifying the remote branch.
Either way, AFAICT it seems purely historical that
"git fetch central master" doesn't update remotes/central.
- Eric
^ permalink raw reply
* [PATCH 1/2] abspath.c: move declaration of 'len' into inner block and use appropriate type
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <vODpKBYr5sNtCfB7C_mUMqGkpPTwc8quzfdAUjySMC_tekZRVbEOpzkstotoeMXAS6wJ4OaF2NA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The 'len' variable was declared at the beginning of the make_absolute_path
function and also in an inner 'if' block which masked the outer declaration.
It is only used in two 'if' blocks, so remove the outer declaration and
make a new declaration inside the other 'if' block that uses 'len'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
abspath.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/abspath.c b/abspath.c
index 4bee0ba..b88122c 100644
--- a/abspath.c
+++ b/abspath.c
@@ -18,7 +18,7 @@ const char *make_absolute_path(const char *path)
{
static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
char cwd[1024] = "";
- int buf_index = 1, len;
+ int buf_index = 1;
int depth = MAXDEPTH;
char *last_elem = NULL;
@@ -50,7 +50,7 @@ const char *make_absolute_path(const char *path)
die_errno ("Could not get current working directory");
if (last_elem) {
- int len = strlen(buf);
+ size_t len = strlen(buf);
if (len + strlen(last_elem) + 2 > PATH_MAX)
die ("Too long path name: '%s/%s'",
buf, last_elem);
@@ -61,7 +61,7 @@ const char *make_absolute_path(const char *path)
}
if (!lstat(buf, &st) && S_ISLNK(st.st_mode)) {
- len = readlink(buf, next_buf, PATH_MAX);
+ ssize_t len = readlink(buf, next_buf, PATH_MAX);
if (len < 0)
die_errno ("Invalid symlink '%s'", buf);
if (PATH_MAX <= len)
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] commit.c: rename variable named 'n' which masks previous declaration
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <vODpKBYr5sNtCfB7C_mUMmQyYO9vzbX98QMYSBId5GcwHT7q6zvrKlJpRNwoJvTTF7qKScin5PA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The variable named 'n' was initially declared to be of type int. The name
'n' was reused inside inner blocks as a different type. Rename the uses
within inner blocks to avoid confusion and give them a slightly more
descriptive name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
commit.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index e2bcbe8..a6c6f70 100644
--- a/commit.c
+++ b/commit.c
@@ -564,13 +564,13 @@ static struct commit_list *merge_bases_many(struct commit *one, int n, struct co
while (interesting(list)) {
struct commit *commit;
struct commit_list *parents;
- struct commit_list *n;
+ struct commit_list *next;
int flags;
commit = list->item;
- n = list->next;
+ next = list->next;
free(list);
- list = n;
+ list = next;
flags = commit->object.flags & (PARENT1 | PARENT2 | STALE);
if (flags == (PARENT1 | PARENT2)) {
@@ -598,11 +598,11 @@ static struct commit_list *merge_bases_many(struct commit *one, int n, struct co
free_commit_list(list);
list = result; result = NULL;
while (list) {
- struct commit_list *n = list->next;
+ struct commit_list *next = list->next;
if (!(list->item->object.flags & STALE))
insert_by_date(list->item, &result);
free(list);
- list = n;
+ list = next;
}
return result;
}
--
1.6.4
^ permalink raw reply related
* [PATCH 0/2] Two janitorial patches
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git
Brandon Casey (2):
abspath.c: move declaration of 'len' into inner block and use
appropriate type
commit.c: rename variable named 'n' which masks previous declaration
abspath.c | 6 +++---
commit.c | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: vc in emacs problem with git
From: Rustom Mody @ 2009-08-27 16:14 UTC (permalink / raw)
To: help-gnu-emacs, Git Mailing List
In-Reply-To: <f46c52560908270828o574c0de6s17189a7326a1376d@mail.gmail.com>
Just updating my own question:
when I do a C-x v v (vc-next-action)
which is supposed to be the most basic operation for checking in a file I get
Wrong type argument: stringp, nil
So vc can be assumed to be a broken I guess?
On Thu, Aug 27, 2009 at 8:58 PM, Rustom Mody<rustompmody@gmail.com> wrote:
> This is emacs 23 using the new 'updated-for-modern-dvcs' vc
> I see a mode line saying (note the colon)
> Git:master
>
> In the info on vc (Version control and the mode line) the emacs manual says:
>
> The character between the back-end name and the revision ID
> indicates the version control status of the file. `-' means that the
> work file is not locked (if locking is in use), or not modified (if
> locking is not in use). `:' indicates that the file is locked, or that
> it is modified.
>
> However at the shell a git status says
> # On branch master
> nothing to commit (working directory clean)
>
> If I close and reopen the file the colon becomes a -
> But I get a message:
>
> `working-revision' not found: using the old `workfile-version' instead.
>
^ permalink raw reply
* Re: [SCuMD]
From: Robin Rosenberg @ 2009-08-27 14:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian Senkowski, git
In-Reply-To: <4A965A1D.3060104@op5.se>
torsdag 27 augusti 2009 12:04:13 skrev Andreas Ericsson <ae@op5.se>:
> Christian Senkowski wrote:
> > Hi,
> >
> > I cloned SCuMD directly via git and started it but got following error:
> >
> > ~/scumd$ ./run.sh
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > com.asolutions.scmsshd.SCuMD
> > at gnu.java.lang.MainThread.run(libgcj.so.90)
> > Caused by: java.lang.ClassNotFoundException:
> > com.asolutions.scmsshd.SCuMD not found in
> > gnu.gcj.runtime.SystemClassLoader{urls=[file:depend/lib/jgit.jar,file:depend/lib/minasshd.jar,file:lib/aopalliance-1.0.jar,file:lib/bcprov-jdk15-140.jar,file:lib/commons-io-1.4.jar,file:lib/commons-logging-1.0.4.jar,file:./,file:lib/jline-0.9.1.jar,file:lib/jline-0.9.94.jar,file:lib/jpam-1.1.jar,file:lib/jsch-0.1.40.jar,file:lib/jzlib-1.0.7.jar,file:lib/log4j-1.2.13.jar,file:lib/slf4j-api-1.5.2.jar,file:lib/slf4j-log4j12-1.4.3.jar,file:lib/spring-beans-2.5.5.jar,file:lib/spring-context-2.5.5.jar,file:lib/spring-core-2.5.5.jar],
> > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> > at java.net.URLClassLoader.findClass(libgcj.so.90)
> > at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
> > at java.lang.ClassLoader.loadClass(libgcj.so.90)
> > at java.lang.ClassLoader.loadClass(libgcj.so.90)
> > at gnu.java.lang.MainThread.run(libgcj.so.90)
> >
> >
> > Please help me out :)
> >
Short answer: Don't run things with GCJ unless you make sure it works
with SUN's java or OPENJDK first. If it still doesn't work ask the GCJ
people for help.
> Please refer to the SCuMD mailing list for this SCuMD related question.
Their README file refers to the Git mailing list. Hence the tag, Kind'o like
JGit, which they depend upon.
-- robin
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 15:36 UTC (permalink / raw)
To: Tom Lambda; +Cc: git
In-Reply-To: <1251387045053-3527289.post@n2.nabble.com>
On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@gmail.com> wrote:
> What was a little bit surprising to me is that running "git fetch central
> master" does not update refs/remotes/central/master but simply updates
> FETCH_HEAD.
I've often wanted this myself, especially when doing things like "git
pull origin master". However, I know the current behaviour is also
useful sometimes, and changing it would introduce an unexpected side
effect. Git currently promises that your refs/remotes/* branches will
never be updated unless you explicitly request it, even if you're
fetching, merging, and pulling other stuff. This means you can write
scripts to do complicated things without triggering unexpected
user-visible side effects.
So basically, I agree that it would often be much more user-friendly
to do what you're asking. But it would be less scripting-friendly. I
don't think anyone has thought of an answer that better balances the
two.
Have fun,
Avery
^ permalink raw reply
* [PATCH] Makefile: remove pointless conditional assignment in SunOS section
From: Brandon Casey @ 2009-08-27 15:35 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
It is true that NEEDS_RESOLV is needed on SunOS if NO_IPV6 is set since
hstrerror() resides in libresolv, but performing this test at its current
location is not very useful. It will only have any effect if the user
modifies the make variables from the make command line, and will have no
effect if a config.mak file is used. A better location for this
conditional would have been further down in the Makefile after the
config.mak and config.mak.autogen had been parsed. Rather than adding
clutter to the Makefile for a conditional that will likely never be
triggered, just remove it, and any user on SunOS that manually sets NO_IPV6
can also set NEEDS_RESOLV.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 66eedef..a9a4d89 100644
--- a/Makefile
+++ b/Makefile
@@ -757,9 +757,6 @@ ifeq ($(uname_S),SunOS)
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
- ifdef NO_IPV6
- NEEDS_RESOLV = YesPlease
- endif
INSTALL = /usr/ucb/install
TAR = gtar
BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__ -DHAVE_ALLOCA_H
--
1.6.4
^ permalink raw reply related
* Question regarding git fetch
From: Tom Lambda @ 2009-08-27 15:30 UTC (permalink / raw)
To: git
I noticed that git-fetch seems smarter when it is run without a <refspec>
argument than when one specifies a branch name. I use a simple setup where a
remote central repository is defined when it is cloned the first time (clone
-o central ...). This leads to these default parameters:
remote.central.fetch=+refs/heads/*:refs/remotes/central/*
branch.master.remote=central
branch.master.merge=refs/heads/master
When I use "git fetch central" each branch in central's refs/heads/ is
automatically fetched to my refs/remotes/central/ as expected.
What was a little bit surprising to me is that running "git fetch central
master" does not update refs/remotes/central/master but simply updates
FETCH_HEAD.
I read the manual and I know that updating FETCH_HEAD is the expected
default behavior for git-fetch. However, I really like the fact that git
fetch (without <refspec>) knows that ANY branch in refs/heads/ corresponds
to refs/remotes/central/. Is there a way to change the configuration to have
"git fetch central branch" always updating refs/remotes/central/branch
whatever the specified branch.
I would prefer not to have to specify the <dst> each time:
git fetch central branch:remotes/central/branch
Thank you,
Tom
--
View this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3527289.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* vc in emacs problem with git
From: Rustom Mody @ 2009-08-27 15:28 UTC (permalink / raw)
To: help-gnu-emacs, Git Mailing List
This is emacs 23 using the new 'updated-for-modern-dvcs' vc
I see a mode line saying (note the colon)
Git:master
In the info on vc (Version control and the mode line) the emacs manual says:
The character between the back-end name and the revision ID
indicates the version control status of the file. `-' means that the
work file is not locked (if locking is in use), or not modified (if
locking is not in use). `:' indicates that the file is locked, or that
it is modified.
However at the shell a git status says
# On branch master
nothing to commit (working directory clean)
If I close and reopen the file the colon becomes a -
But I get a message:
`working-revision' not found: using the old `workfile-version' instead.
^ permalink raw reply
* git-svn intermittent issues with absent_file
From: Matthias Andree @ 2009-08-27 14:56 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Greetings,
we seem to have issues with checking out files from an SVN server via
https://. The problem is hard to reproduce, and shows as "absent_file"
warnings, i. e. files that are in the SVN checkout don't make it to the
Git checkin.
Perhaps this rings a bell with someone or there are similar reports that
relate to our issues...
## ISSUE ## Once in a while, a git-svn clone or rebase fails with files
missing from commits, as mentioned above. We haven't been able to figure
out under what circumstances this happens. If we try to reproduce this (i.
e. kill the directory completely and re-run the git svn clone), another
revision (for instance 170) might show this, or the clone may succeed.
This was observed with Git 1.6.0.4 under Ubuntu Linux Jaunty Jackalope
(9.04) and on a different computer with Git 1.6.4.1.196.g31f0b (from the
master branch) under a fully updated Cygwin 1.5.
Example log of failed data (sorry, we are not allowed to let you access
the repository, so we must debug by proxy).
I'm replacing substrings in the log below to maintain corporate
confidentiality levels:
$ git svn clone --no-checkout https://svnserver.example.edu/project/
Initialized empty Git repository in /tmp/compnet/.git/
W: +empty_dir: branches
W: +empty_dir: tags
W: +empty_dir: trunk
r1 = a1b0e99e3986da4d8d461944b623b6abb2460de4 (refs/remotes/git-svn)
...
r135 = 294077e62ee5f463b8ab97d961d9742ef89ae662 (refs/remotes/git-svn)
A ... (~100 PDF files)
...
A d1/u1/2009_06/f1.pdf
W: +empty_dir: d1/u2/slides/2009_06
W: absent_file: d1/u1/2009_06/d1/u1/2009_06/f2.pdf Insufficient
permissions?
W: absent_file: d1/u3/06_2009/f1/u3/2009_06/f3.pdf Insufficient
permissions?
W: absent_file: d1/u2/slides/2009_06/d1/u2/slides/2009_06/f4.pdf
Insufficient permissions?
r136 = 58523cf1fa867d33a74080dabdcbc85ae0ba99ec (refs/remotes/git-svn)
...
r139 = 2fb1647bc40d3815a5eefb32d43a375e03d2e871 (refs/remotes/git-svn)
Incomplete data: Delta source ended unexpectedly at
/usr/local/libexec/git-core/git-svn line 4605
Just re-running "git svn fetch" reproduces the "Incomplete data:" error
and aborts, but re-fetching an older version succeeds. No fiddling with
permissions needed.
## WORKAROUND ##
If this happens, I can force a checkout with, say, "git checkout -t -b
master remotes/git-svn", revert to the last good revision with "git svn
reset -r135" (this doesn't work without prior checkout) and then re-run
git svn fetch, which will usually succeed then.
The three absent_file lines are also recorded in
.git/svn/refs/remotes/git-svn/unhandled.log for r136.
Questions:
1. What causes these absent_file issues? How can we assist with debugging
this?
2. What does "Delta source ended unexpectedly" mean? (the line number is
bogus, it's just the finish_report call)
3. Is this or a similar issue known? Is this an issue with the SVN server,
the SVN bindings, or the git svn adaptor?
4. How can we avoid or fix this?
We're happy to test patches.
Thanks a lot in advance.
Cheers,
--
Matthias Andree
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Thiago Farina @ 2009-08-27 14:26 UTC (permalink / raw)
To: Frank Li
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <1976ea660908270616v543776fdv6ec167cc105337fc@mail.gmail.com>
Hi
On Thu, Aug 27, 2009 at 10:16 AM, Frank Li<lznuaa@gmail.com> wrote:
> I fixed this problem
> It should be ext/zlib
>
Thanks!
Now when I run 'git submodule update' I recieve this error:
'fatal: Needed a single revision
Unable to find the current revision in submodule path 'ext/OpenSSL''
If the output of 'git submodule status' help, this is:
fdd0f73b9a3e7c1fdf15c2e2a52582c637ec96f1 ext/OpenSSL
+3136d3b72e199ad1484629e8ff4563a918cad953 ext/git (remotes/origin/vcpatch)
-c891963b1c9d2ffbf194b2c2283639d784fa3690 ext/libcurl
-62cb93cb25e2fbdbc89f90249cd8a024afad8a94 ext/zlib
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Jakub Narebski @ 2009-08-27 13:33 UTC (permalink / raw)
To: Johan Sorensen
Cc: Junio C Hamano, Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <9e0f31700908270509o1031a027y1b49efe7ea9a4fd3@mail.gmail.com>
Johan Sorensen <johan@johansorensen.com> writes:
> On Thu, Aug 27, 2009 at 2:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> > After upload-pack successfully finishes its operation, post-upload-pack
> > hook can be called for logging purposes.
> >
> > The hook is passed various pieces of information, one per line, from its
> > standard input. Currently the following items can be fed to the hook, but
> > more types of information may be added in the future:
> >
> > want SHA-1::
> > 40-byte hexadecimal object name the client asked to include in the
> > resulting pack. Can occur one or more times in the input.
> >
> > have SHA-1::
> > 40-byte hexadecimal object name the client asked to exclude from
> > the resulting pack, claiming to have them already. Can occur zero
> > or more times in the input.
> >
> > time float::
> > Number of seconds spent for creating the packfile.
> >
> > size decimal::
> > Size of the resulting packfile in bytes.
>
> Neat. And feeding it lines gives more room for future additions.
>
> I'd like to suggest the following line from the original patch:
>
> full-pack integer::
> 1 if the request was considered a full clone, 0 if it was a
> partial update (fetch)
If it is all "want" and no "have", it is clone or fetch into empty
repository. If additionaly "want"s cover all refs, it is a clone.
No need to pass this information: it can be derived.
> Also, on a similar note; in the little git-daemon (a tiny fork+exec
> server in ruby) included with Gitorious there's a geo-ip lookup based
> on the client addr. It would be fun if the client ip could be passed
> along to this hook as well, but that would require passing it along
> all the way from before fetch-pack is invoked as far as I can see..?
Well, we can pass at least `client-ip`...
[please don't quote what is not needed]
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Frank Li @ 2009-08-27 13:16 UTC (permalink / raw)
To: Thiago Farina
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <a4c8a6d00908251024o24380f7ue409ac5f164c085e@mail.gmail.com>
>
> [submodule "ext\\zlib"]
> path = ext\\zlib
> url = git://repo.or.cz/zlib.git
>
I fixed this problem
It should be ext/zlib
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Johan Sørensen @ 2009-08-27 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <7vy6p69j6a.fsf@alter.siamese.dyndns.org>
On Thu, Aug 27, 2009 at 2:47 AM, Junio C Hamano<gitster@pobox.com> wrote:
> After upload-pack successfully finishes its operation, post-upload-pack
> hook can be called for logging purposes.
>
> The hook is passed various pieces of information, one per line, from its
> standard input. Currently the following items can be fed to the hook, but
> more types of information may be added in the future:
>
> want SHA-1::
> 40-byte hexadecimal object name the client asked to include in the
> resulting pack. Can occur one or more times in the input.
>
> have SHA-1::
> 40-byte hexadecimal object name the client asked to exclude from
> the resulting pack, claiming to have them already. Can occur zero
> or more times in the input.
>
> time float::
> Number of seconds spent for creating the packfile.
>
> size decimal::
> Size of the resulting packfile in bytes.
Neat. And feeding it lines gives more room for future additions.
I'd like to suggest the following line from the original patch:
full-pack integer::
1 if the request was considered a full clone, 0 if it was a
partial update (fetch)
Also, on a similar note; in the little git-daemon (a tiny fork+exec
server in ruby) included with Gitorious there's a geo-ip lookup based
on the client addr. It would be fun if the client ip could be passed
along to this hook as well, but that would require passing it along
all the way from before fetch-pack is invoked as far as I can see..?
JS
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
> > Here is an illustration patch.
>
> And here is a bit more polished one with necessary supporting material.
>
> Documentation/git-upload-pack.txt | 2 +
> Documentation/githooks.txt | 25 +++++++++++++
> t/t5501-post-upload-pack.sh | 49 ++++++++++++++++++++++++++
> upload-pack.c | 68 +++++++++++++++++++++++++++++++++++-
> 4 files changed, 142 insertions(+), 2 deletions(-)
> create mode 100755 t/t5501-post-upload-pack.sh
>
> diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
> index b8e49dc..63f3b5c 100644
> --- a/Documentation/git-upload-pack.txt
> +++ b/Documentation/git-upload-pack.txt
> @@ -20,6 +20,8 @@ The UI for the protocol is on the 'git-fetch-pack' side, and the
> program pair is meant to be used to pull updates from a remote
> repository. For push operations, see 'git-send-pack'.
>
> +After finishing the operation successfully, `post-upload-pack`
> +hook is called (see linkgit:githooks[5]).
>
> OPTIONS
> -------
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 1c73673..036f6c7 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -307,6 +307,31 @@ Both standard output and standard error output are forwarded to
> 'git-send-pack' on the other end, so you can simply `echo` messages
> for the user.
>
> +post-upload-pack
> +----------------
> +
> +After upload-pack successfully finishes its operation, this hook is called
> +for logging purposes.
> +
> +The hook is passed various pieces of information, one per line, from its
> +standard input. Currently the following items can be fed to the hook, but
> +more types of information may be added in the future:
> +
> +want SHA-1::
> + 40-byte hexadecimal object name the client asked to include in the
> + resulting pack. Can occur one or more times in the input.
> +
> +have SHA-1::
> + 40-byte hexadecimal object name the client asked to exclude from
> + the resulting pack, claiming to have them already. Can occur zero
> + or more times in the input.
> +
> +time float::
> + Number of seconds spent for creating the packfile.
> +
> +size decimal::
> + Size of the resulting packfile in bytes.
> +
> pre-auto-gc
> -----------
>
> diff --git a/t/t5501-post-upload-pack.sh b/t/t5501-post-upload-pack.sh
> new file mode 100755
> index 0000000..2cb63f8
> --- /dev/null
> +++ b/t/t5501-post-upload-pack.sh
> @@ -0,0 +1,49 @@
> +#!/bin/sh
> +
> +test_description='post upload-hook'
> +
> +. ./test-lib.sh
> +
> +LOGFILE=".git/post-upload-pack-log"
> +
> +test_expect_success setup '
> + test_commit A &&
> + test_commit B &&
> + git reset --hard A &&
> + test_commit C &&
> + git branch prev B &&
> + mkdir -p .git/hooks &&
> + {
> + echo "#!$SHELL_PATH" &&
> + echo "cat >post-upload-pack-log"
> + } >".git/hooks/post-upload-pack" &&
> + chmod +x .git/hooks/post-upload-pack
> +'
> +
> +: test_expect_success initial '
> + rm -fr sub &&
> + git init sub &&
> + (
> + cd sub &&
> + git fetch --no-tags .. prev
> + ) &&
> + want=$(sed -n "s/^want //p" "$LOGFILE") &&
> + test "$want" = "$(git rev-parse --verify B)" &&
> + ! grep "^have " "$LOGFILE"
> +'
> +
> +test_expect_success second '
> + rm -fr sub &&
> + git init sub &&
> + (
> + cd sub &&
> + git fetch --no-tags .. prev:refs/remotes/prev &&
> + git fetch --no-tags .. master
> + ) &&
> + want=$(sed -n "s/^want //p" "$LOGFILE") &&
> + test "$want" = "$(git rev-parse --verify C)" &&
> + have=$(sed -n "s/^have //p" "$LOGFILE") &&
> + test "$have" = "$(git rev-parse --verify B)"
> +'
> +
> +test_done
> diff --git a/upload-pack.c b/upload-pack.c
> index 4d8be83..69a6f46 100644
> --- a/upload-pack.c
> +++ b/upload-pack.c
> @@ -141,8 +141,60 @@ static int do_rev_list(int fd, void *create_full_pack)
> return 0;
> }
>
> +static int feed_obj_to_hook(const char *label, struct object_array *oa, int i, int fd)
> +{
> + int cnt;
> + char buf[512];
> +
> + cnt = sprintf(buf, "%s %s\n", label,
> + sha1_to_hex(oa->objects[i].item->sha1));
> + return write_in_full(fd, buf, cnt) != cnt;
> +}
> +
> +static int run_post_upload_pack_hook(size_t total, struct timeval *tv)
> +{
> + const char *argv[2];
> + struct child_process proc;
> + int err, i;
> + int cnt;
> + char buf[512];
> +
> + argv[0] = "hooks/post-upload-pack";
> + argv[1] = NULL;
> +
> + if (access(argv[0], X_OK) < 0)
> + return 0;
> +
> + memset(&proc, 0, sizeof(proc));
> + proc.argv = argv;
> + proc.in = -1;
> + proc.stdout_to_stderr = 1;
> + err = start_command(&proc);
> + if (err)
> + return err;
> + for (i = 0; !err && i < want_obj.nr; i++)
> + err |= feed_obj_to_hook("want", &want_obj, i, proc.in);
> + for (i = 0; !err && i < have_obj.nr; i++)
> + err |= feed_obj_to_hook("have", &have_obj, i, proc.in);
> + if (!err) {
> + cnt = sprintf(buf, "time %ld.%06ld\n",
> + (long)tv->tv_sec, (long)tv->tv_usec);
> + err |= (write_in_full(proc.in, buf, cnt) != cnt);
> + }
> + if (!err) {
> + cnt = sprintf(buf, "size %ld\n", (long)total);
> + err |= (write_in_full(proc.in, buf, cnt) != cnt);
> + }
> + if (close(proc.in))
> + err = 1;
> + if (finish_command(&proc))
> + err = 1;
> + return err;
> +}
> +
> static void create_pack_file(void)
> {
> + struct timeval start_tv, tv;
> struct async rev_list;
> struct child_process pack_objects;
> int create_full_pack = (nr_our_refs == want_obj.nr && !have_obj.nr);
> @@ -150,10 +202,12 @@ static void create_pack_file(void)
> char abort_msg[] = "aborting due to possible repository "
> "corruption on the remote side.";
> int buffered = -1;
> - ssize_t sz;
> + ssize_t sz, total_sz;
> const char *argv[10];
> int arg = 0;
>
> + gettimeofday(&start_tv, NULL);
> + total_sz = 0;
> if (shallow_nr) {
> rev_list.proc = do_rev_list;
> rev_list.data = 0;
> @@ -262,7 +316,7 @@ static void create_pack_file(void)
> sz = xread(pack_objects.out, cp,
> sizeof(data) - outsz);
> if (0 < sz)
> - ;
> + total_sz += sz;
> else if (sz == 0) {
> close(pack_objects.out);
> pack_objects.out = -1;
> @@ -314,6 +368,16 @@ static void create_pack_file(void)
> }
> if (use_sideband)
> packet_flush(1);
> +
> + gettimeofday(&tv, NULL);
> + tv.tv_sec -= start_tv.tv_sec;
> + if (tv.tv_usec < start_tv.tv_usec) {
> + tv.tv_sec--;
> + tv.tv_usec += 1000000;
> + }
> + tv.tv_usec -= start_tv.tv_usec;
> + if (run_post_upload_pack_hook(total_sz, &tv))
> + warning("post-upload-hook failed");
> return;
>
> fail:
> --
> 1.6.4.1.288.g10d22
>
> --
> 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
>
^ permalink raw reply
* Re: [RFC] Use a 16-tree instead of a 256-tree for storing notes
From: Johannes Schindelin @ 2009-08-27 11:56 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Alex Riesen, Johan Herland, git, gitster, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <4A95383A.4080104@op5.se>
Hi,
On Wed, 26 Aug 2009, Andreas Ericsson wrote:
> If it's to be squashed in, why mention the 256-tree at all
It was labeled RFC, so I think it is perfectly fine to compare with other
contenders.
Thanks,
Dscho
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Johannes Schindelin @ 2009-08-27 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vprahyfk4.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 26 Aug 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> mailsplit.scissors
> >
> > Sorry, did not have time to read this thread properly, but has anybody put
> > thought into the interaction between this patch and "git rebase" (which
> > uses "git am", and therefore mailsplit, internally)?
>
> I was looking around this area tonight (I promised I won't touch the
> definition of scissors, but I never said I won't work on making it
> usable), as I originally shared the same worry with you.
>
> It turns out that "rebase" invokes "am" with the "--rebasing" option.
> Under this option, "am" uses an equivalent of "commit -C $commit"
> internally to port the message forward. So our worries are unfounded.
Thank you very much! This relieves me, indeed.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johannes Schindelin @ 2009-08-27 10:47 UTC (permalink / raw)
To: Johan Herland
Cc: Junio C Hamano, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <200908271135.31794.johan@herland.net>
Hi,
On Thu, 27 Aug 2009, Johan Herland wrote:
> On Thursday 27 August 2009, Junio C Hamano wrote:
> > Somebody up in the project is supposed to decide what fan-out is to be
> > used for the whole project and everybody should follow that structure?
>
> Nope, the code should decide which fanout scheme to use.
I half-agree, the code should decide which fanout scheme to use, but
_only_ when producing new notes.
I imagine that it could merge the existing notes, and try to make sure
that there are no more blobs in a given subtree than a certain threshold;
if that threshold is reached, it could fan-out using 2-digit subtrees,
merging what needs merging (by concatenation) along the way.
The natural precedence of shallower paths/longer basenames should cope
well with that (i.e. prefer to show abcd/... over ab/cd/...).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johannes Schindelin @ 2009-08-27 10:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johan Herland, git, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <7v7hwp6ebb.fsf@alter.siamese.dyndns.org>
Hi,
On Wed, 26 Aug 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > The semantics used when parsing notes trees (with regards to fanout subtrees)
> > follow Dscho's proposal fairly closely:
> > - No concatenation/merging of notes is performed. If there are several notes
> > objects referencing a given commit, only one of those objects are used.
> > - If a notes object for a given commit is present in the "root" notes tree,
> > no subtrees are consulted; the object in the root tree is used directly.
> > - If there are more than one subtree that prefix-matches the given commit,
> > only the subtree with the longest matching prefix is consulted. This
> > means that if the given commit is e.g. "deadbeef", and the notes tree have
> > subtrees "de" and "dead", then the following paths in the notes tree are
> > searched: "deadbeef", "dead/beef". Note that "de/adbeef" is NOT searched.
> > - Fanout directories (subtrees) must references a whole number of bytes
> > from the SHA1 sum they subdivide. E.g. subtrees "dead" and "de" are
> > acceptable; "d" and "dea" are not.
> > - Multiple levels of fanout are allowed. All the above rules apply
> > recursively. E.g. "de/adbeef" is preferred over "de/adbe/ef", etc.
>
> If I am reading this correctly, the earlier parts of the series were
> aiming to let multiple people to add notes to the same commit more or less
> uncordinated while still allowing to merge them sensibly, but now such a
> workflow becomes impossible with this change.
>
> The above claims notes trees with different levels of fan-out are allowed,
> but what it really means is that merging notes trees with different levels
> of fan-out will produce a useless result that records notes for the same
> commit in different blobs all over the notes tree, and asking the notes
> mechanism to give the notes for one commit will give only one piece that
> originates in the tree whose creator happened to have used the longest
> prefix while ignoring all others. It may _allow_ such a layout, but how
> would such semantics be useful in the first place?
>
> I suspect that I am missing something but my gut feeling is that this
> change turns an interesting hack (even though it might be expensive) into
> a hack that is not useful at all in the real world, without some order,
> discipline, or guideline is applied.
>
> What's the recommended way to work with this system from the end user's
> point of view in a distirbuted environment? Somebody up in the project is
> supposed to decide what fan-out is to be used for the whole project and
> everybody should follow that structure? If a participant in the project
> forgets that rule (or makes a mistake), a notes tree that mistakenly
> merges his notes tree becomes practically useless? If so, perhaps we
> would need a mechanism to avoid such a mistake from happening?
Hmm...
Maybe you're right (and mugwump was right all along) that _all_ matching
notes should be shown...
Ciao,
Dscho
^ permalink raw reply
* Re: [SCuMD]
From: Andreas Ericsson @ 2009-08-27 10:04 UTC (permalink / raw)
To: Christian Senkowski; +Cc: git
In-Reply-To: <4A965799.6050204@gmx.de>
Christian Senkowski wrote:
> Hi,
>
> I cloned SCuMD directly via git and started it but got following error:
>
> ~/scumd$ ./run.sh
> Exception in thread "main" java.lang.NoClassDefFoundError:
> com.asolutions.scmsshd.SCuMD
> at gnu.java.lang.MainThread.run(libgcj.so.90)
> Caused by: java.lang.ClassNotFoundException:
> com.asolutions.scmsshd.SCuMD not found in
> gnu.gcj.runtime.SystemClassLoader{urls=[file:depend/lib/jgit.jar,file:depend/lib/minasshd.jar,file:lib/aopalliance-1.0.jar,file:lib/bcprov-jdk15-140.jar,file:lib/commons-io-1.4.jar,file:lib/commons-logging-1.0.4.jar,file:./,file:lib/jline-0.9.1.jar,file:lib/jline-0.9.94.jar,file:lib/jpam-1.1.jar,file:lib/jsch-0.1.40.jar,file:lib/jzlib-1.0.7.jar,file:lib/log4j-1.2.13.jar,file:lib/slf4j-api-1.5.2.jar,file:lib/slf4j-log4j12-1.4.3.jar,file:lib/spring-beans-2.5.5.jar,file:lib/spring-context-2.5.5.jar,file:lib/spring-core-2.5.5.jar],
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> at java.net.URLClassLoader.findClass(libgcj.so.90)
> at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
> at java.lang.ClassLoader.loadClass(libgcj.so.90)
> at java.lang.ClassLoader.loadClass(libgcj.so.90)
> at gnu.java.lang.MainThread.run(libgcj.so.90)
>
>
> Please help me out :)
>
Please refer to the SCuMD mailing list for this SCuMD related question.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* [SCuMD]
From: Christian Senkowski @ 2009-08-27 9:53 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
Hi,
I cloned SCuMD directly via git and started it but got following error:
~/scumd$ ./run.sh
Exception in thread "main" java.lang.NoClassDefFoundError:
com.asolutions.scmsshd.SCuMD
at gnu.java.lang.MainThread.run(libgcj.so.90)
Caused by: java.lang.ClassNotFoundException:
com.asolutions.scmsshd.SCuMD not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:depend/lib/jgit.jar,file:depend/lib/minasshd.jar,file:lib/aopalliance-1.0.jar,file:lib/bcprov-jdk15-140.jar,file:lib/commons-io-1.4.jar,file:lib/commons-logging-1.0.4.jar,file:./,file:lib/jline-0.9.1.jar,file:lib/jline-0.9.94.jar,file:lib/jpam-1.1.jar,file:lib/jsch-0.1.40.jar,file:lib/jzlib-1.0.7.jar,file:lib/log4j-1.2.13.jar,file:lib/slf4j-api-1.5.2.jar,file:lib/slf4j-log4j12-1.4.3.jar,file:lib/spring-beans-2.5.5.jar,file:lib/spring-context-2.5.5.jar,file:lib/spring-core-2.5.5.jar],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.90)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at gnu.java.lang.MainThread.run(libgcj.so.90)
Please help me out :)
Kind regards,
C. Senkowski
--
Christian Senkowski
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]
^ permalink raw reply
* Re: [PATCHv4 10/12] notes.c: Implement simple memory pooling of leaf nodes
From: Johan Herland @ 2009-08-27 9:49 UTC (permalink / raw)
To: git
Cc: Alex Riesen, gitster, Johannes.Schindelin, trast, tavestbo, git,
chriscool, spearce
In-Reply-To: <81b0412b0908270039l7a937c3bmd745274c71526ce1@mail.gmail.com>
On Thursday 27 August 2009, Alex Riesen wrote:
> On Thu, Aug 27, 2009 at 03:43, Johan Herland<johan@herland.net> wrote:
> > When allocating a new memory pool, the older pool is leaked, but this
> > is no worse than the current situation, where (pretty much) all
> > leaf_nodes are leaked anyway.
>
> Could you return the unused nodes back into the mempool?
> By making the pool a preallocated list, perhaps?
Yes, maintaining a free-list is certainly possible. However, the number of
free()d leaf_nodes is relatively small (only subtree entries are free()d
after unpacking them into the tree structure), so I'm not sure it pays off,
runtime-wise.
> And then it is trivial to provide a deallocation function for the
> mempool, which something really concerned about the memleak can call
> (like when or if libgit get more usable in an application context).
Yes, I plan to provide a free_notes() function that free()s all the memory
associated with the notes data structure. This would of course keep
references to all the mempools, and deallocate them (along with all the
int_nodes).
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ 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