* Re: How to make Cogito use git-fetch-pack?
From: Petr Baudis @ 2005-09-24 1:19 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <43347F98.6020101@zytor.com>
Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Is there any way to make Cogito use git-fetch-pack instead of
> git-ssh-fetch? git+ssh:// seems to invoke the latter.
I just added git+packed+ssh:// to be used for this purpose.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* The latest commit to add new keybindings
From: Junio C Hamano @ 2005-09-24 1:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
Paul, I was looking at the gitk repository thinking it's about
time for me to slurp your changes in, and have two questions.
The 'new keybindings' commit from Robert Suetterlin changes the
beginning of gitk to:
--- a/gitk
+++ b/gitk
@@ -1,6 +1,6 @@
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
-exec wish "$0" -- "${1+$@}"
+exec wish8.4 "$0" -- "${1+$@}"
Do you actually require 8.4, or any reasonably recent wish would
do? The reason I ask is that Debian side (debian/control)
explicitly depends on 'tk8.4' but RPM side (git-core.spec.in)
just says 'tk'. I could change the RPM side to also require 8.4
but I do not have ready access to any RPM machine to test it
with, so if that is not needed I'd rather not touch spec.in
file.
Another thing, which is unrelated to Robert's change, is that I
suspect the exec command line should be like either one of these
(the first one is probably more old-fashioned):
exec wish "$0" -- ${1+"$@"}
exec wish "$0" -- "$@"
With "${1+$@}", you are passing an empty parameter after '--'
when gitk itself receives no parameter. Maybe it is intended,
maybe not...
prompt$ cat >one.sh <<\EOF
#!/bin/sh
exec ./two.sh "$0" -- "${1+$@}"
EOF
prompt$ cat >two.sh <<\EOF
#!/bin/sh
echo "\$0 is $0"
echo "\$# is $#"
i=1
for a
do
echo "\$$i is $a"
i=`expr $i + 1`
done
EOF
prompt$ chmod +x one.sh two.sh
prompt$ ./one.sh foo
$0 is /var/tmp/gomi/two.sh
$# is 3
$1 is <./one.sh>
$2 is <-->
$3 is <foo>
prompt$ ./one.sh
$0 is /var/tmp/gomi/two.sh
$# is 3
$1 is <./one.sh>
$2 is <-->
$3 is <>
prompt$ exit
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: H. Peter Anvin @ 2005-09-24 1:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050924011833.GJ10255@pasky.or.cz>
Petr Baudis wrote:
>
> It takes loooong time, unfortunately - scp -r takes its time itself on
> many small files, and then we have to make a separate call to
> git-ssh-fetch for each tag. Isn't that braindamaged... :/
>
Perhaps git-ssh-fetch should be fixed? :)
-hpa
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-24 2:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050924011833.GJ10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> It takes loooong time, unfortunately - scp -r takes its time itself on
> many small files, and then we have to make a separate call to
> git-ssh-fetch for each tag. Isn't that braindamaged... :/
I think you could run git-peek-remote to find all the refs and
then run git-fetch-pack to slurp all the tags (and heads for
that matter) at once. Is there a particular reason you would
prefer the commit walker?
^ permalink raw reply
* Re: How to make Cogito use git-fetch-pack?
From: H. Peter Anvin @ 2005-09-24 2:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20050924011912.GK10255@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Sat, Sep 24, 2005 at 12:20:08AM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> told me that...
>
>>Is there any way to make Cogito use git-fetch-pack instead of
>>git-ssh-fetch? git+ssh:// seems to invoke the latter.
>
> I just added git+packed+ssh:// to be used for this purpose.
>
Since git tends to use "pack" (e.g. git-fetch-pack) I'd suggest use
git+pack+ssh:// instead. It's shorter, too.
-hpa
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 2:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter TB Brett, Git Mailing List, Davide Libenzi
In-Reply-To: <Pine.LNX.4.63.0509240305450.26220@wgmdd8.biozentrum.uni-wuerzburg.de>
On Sat, 24 Sep 2005, Johannes Schindelin wrote:
>
> BTW I am fairly convinced that the same issues would trouble a git-pull,
> once the networking is running, since the pack transfer relies on
> fork()ing.
I'm not sure.
Almost all other fork() users end up doing a more-or-less immediate
execve() after the fork. Yes, they do some other minor setup, but not a
whole lot.
The diff.c fork() is somewhat different. It actually ends up doing malloc
and stdio IO before it actually gets to the exec(), so that one is more
likely to hit any bugs in the fork() implementation.
Actually, looking a bit closer, the create_pack_file() thing also does
malloc inside the child, but at least there it would be trivial to move
that argument setup code into the parent.
But looking at send_pack() or fetch_pack(), for example, they are both
_very_ traditional fork()+exec() calls, with just a few close() calls in
between.
Looking a bit closer at the diff() usage, I actually think that we could
move the fork() closer to the exec - we'd just have to move it _into_ all
the different cases (ie you'd have two different fork() calls: one for
the "builtin" case, one for the external pgm case, but then the child in
both cases would be very simple).
Oh. Actually, I wonder if we could mke them "vfork()" calls. Does anybody
know if cygwin has an easier time with vfork() + eventual exec? That
_should_ map better to a non-UNIX process model, so maybe we could do it
that way?
> It sure would be nice to have a unified diff generator included, but I
> doubt that a reliable (=simple) one is easy to come by.
Yeah, I looked at GNU diffutils, and I had to rinse out my eyes with soap
and water.
Linus
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Junio C Hamano @ 2005-09-24 3:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0509231935360.3308@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Looking a bit closer at the diff() usage, I actually think that we could
> move the fork() closer to the exec - we'd just have to move it _into_ all
> the different cases (ie you'd have two different fork() calls: one for
> the "builtin" case, one for the external pgm case, but then the child in
> both cases would be very simple).
Looking back at what I did in the diff.c, I actually think the
part near fork() is a total crap ;-).
Originally I intended to do more work in the child process (this
is totally opposite of what is being proposed now), for example
running prepare_temp_file() after child forked, so that the
parent process does not have to worry about using memory for
expanded blob to be written out to the temporary file and then
later forgetting to free it ;-), but it seems the parent is
doing more work than I intended to. I honestly think that the
part of the code is ancient enough to deserve a major facelift.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Peter TB Brett, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509231647300.3308@g5.osdl.org>
On Fri, 23 Sep 2005, Linus Torvalds wrote:
>
>
> On Fri, 23 Sep 2005, Johannes Schindelin wrote:
>>
>> It seems that the fixup of the mmap()ed regions after a fork() does not
>> work properly in cygwin. Remember that cygwin just wraps the non-POSIX
>> Win32API and tries to make it sort of POSIX compliant. The problem is that
>> Win32API lacks a proper fork(). This is therefore emulated, and after
>> that, all the mmap()ed regions have to be mapped again. That fails.
>
> Now, I'm not a big fan of windows ("No, really? Tell us more!") but I'd
> actually like it if the _core_ git stuff worked in as wide a variety of
> situations as possible. Screw the shell scripts and the daemon or
> secondary things like that which windows users might as well generate
> their own stuff for, but I'd hope the really core stuff would work.
>
> If I understood correctly, you said that "git-diff-tree" doesn't work due
> to the fork/mmap issue. Now, I assume that means that it's the builtin
> diff that has problems.
Stay away from Cygwin if you use extensively fork(), since it becomes dog
slow (the fork() implementation on Cygwin involves creating a new
suspended task, *copy* - not COW - the *whole* VM space to the child,
and resuming it). Actually, the whole Cygwin in general is dog slow,
especially on FS operations (and git likes them). If you really like to
have Windows support (uuu hoo WinTorvalds) you might be better using a
small compat layer (should be fairly small for git).
> As far as I can tell, we can solve that two ways:
>
> - make Windows always use the external diff program. That may be the
> right thing to do, since then the fork() just turns into a regular
> fork+exec, which is how windows works anyway.
>
> - look at doing the diff internally.
>
> I'm wondering if there is some stupid way to turn a diff generated by
> diff_delta() into a line-based one? If you have the original file and the
> xdiff, I think we should be able to just walk the original file and output
> a unified diff.
>
> Davide, maybe I'm being stupid, but I'm thinking that it might be possible
> to generate a -u3 diff by basically walking the xdiff file in a linear
> fashion: if the edits are in strictly ascending order, we could walk the
> original file one line at a time, and keeping a buffer of the three last
> lines. Then, when the file offset hits the next "edit" in the xdiff, we
> start generating a line-based diff (and use the previous three lines as
> the context).
>
> Does that sound possible? Maybe somebody has even done it? Is it a stupid
> idea?
>
> I realize that it might not generate the same diff as GNU diff would do,
> and maybe it's really nasty, but it sounds like it _could_ be a "cheap"
> way of generating diffs, considering that we have something that already
> generates xdiffs..
Hehe, the same library from where Nicolas lifted the code for the binary
diff, has a totally portable diff/patch APIs (on top of xdiff/xpach):
http://www.xmailserver.org/xdiff.html
Generating text diffs, unfortunately is quite more complex than binary
ones. Libxdiff uses the same algorithm of GNU diff (Eugene W. Myers). The
library has zero dependency other than ANSI C. Another alternative, IIRC
someone made a library by wrapping the diffutil stuff, but I do not
remeber where it was.
- Davide
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 5:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Peter TB Brett, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509231935360.3308@g5.osdl.org>
On Fri, 23 Sep 2005, Linus Torvalds wrote:
> But looking at send_pack() or fetch_pack(), for example, they are both
> _very_ traditional fork()+exec() calls, with just a few close() calls in
> between.
>
> Looking a bit closer at the diff() usage, I actually think that we could
> move the fork() closer to the exec - we'd just have to move it _into_ all
> the different cases (ie you'd have two different fork() calls: one for
> the "builtin" case, one for the external pgm case, but then the child in
> both cases would be very simple).
>
> Oh. Actually, I wonder if we could mke them "vfork()" calls. Does anybody
> know if cygwin has an easier time with vfork() + eventual exec? That
> _should_ map better to a non-UNIX process model, so maybe we could do it
> that way?
If you have only to run diff/patch, just use the native Win32 CreateProcess().
You abstract that on a git_exec(), and you use fork/exec on Unix and
CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is
pathetic. They do all that work to give you a fork(), and you throw it
away with an exec().
- Davide
^ permalink raw reply
* Re: Please undo "Use git-merge instead of git-resolve in
From: Junio C Hamano @ 2005-09-24 6:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050923095742.GC10255@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Fri, Sep 23, 2005 at 11:34:16AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
>> Petr Baudis <pasky@suse.cz> writes:
>>
>> > * cg-fetch can do with symlinked object database
>>
>> Do you mean ".git/object" in the repository you are fetching
>> into is a symlink to somewhere, or something else?
>
> Yes, exactly that. You get it by doing cg-clone -l
> /local/path.
git-clone -l -s does optimization similar to that in spirit, but
it does not create a repository with symlinked .git/object
pointing at /some/where/original/repo/.git/object. Instead it
uses alternates to borrow from the other; newly created objects
are always stored locally.
But I thought you were talking about fetch. git-fetch should be
able to pull into a repository whose .git/object happens to be a
symlink pointing at somewhere else just fine.
> Just that if the reference pointer did not change, you don't try to pull
> any objects.
Both git-aware protocol and commit walker peek at the remote ref
and stop without downloading objects if it is known to us, so I
think we are OK.
>> $ git-init-db && git fetch http://kernel.org/pub/scm/git/git.git
>>
>> should work.
>
> Good.
Of course, the above 'git fetch' only fetches remote HEAD and
stores it in .git/FETCH_HEAD; if you truly want to 'clone', you
could first run git-ls-remote to peek the remote refs and then
give them as storing refspecs to git fetch, doing something like
this (modulo renaming 'master' over there to 'origin' here):
mkdir foo && cd foo && git-init-db
refspec=$(git-ls-remote $repo | \
sed -n -e 's/^[0-9a-f]* //' -e 's|refs/.*|&:&|p')
git fetch $repo $refspec
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Petr Baudis @ 2005-09-24 12:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvf0r6x97.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > It takes loooong time, unfortunately - scp -r takes its time itself on
> > many small files, and then we have to make a separate call to
> > git-ssh-fetch for each tag. Isn't that braindamaged... :/
>
> I think you could run git-peek-remote to find all the refs and
> then run git-fetch-pack to slurp all the tags (and heads for
> that matter) at once. Is there a particular reason you would
> prefer the commit walker?
Actually, probably not, except consistency with rsync and http handling
- but that's obviously not too good reason. I did it this way since I'm
going to be a bit busy again from now on.
I will probably rewrite the tags fetching to use git-peek-remote
(info/refs for http) the next weekend. One problem with this is that in
many repositories, git-update-server-info does not get ever run and
things would break "mysteriously". I don't want the policy that the user
has to take care of this on his own for Cogito, so I will probably add
something that will automagically append git-update-server-info at least
to the post-update hook (like
uphook="$_git/hooks/update-post"
if ! [ -x "$uphook" ]; then
if ! [ -e "$uphook" ]; then
echo '#!/bin/sh' >>"$uphook"
echo 'exec git-update-server-info' >>"$uphook"
fi
# If the user added something custom and left the hook
# disabled, he knew what he was doing. Also don't
# reenable the hook if we already did that once.
if [[ "$(grep -v '^#\($\|[^#]\)\|^$' "$uphook")" == "*exec git-update-server-info*" ]]; then
chmod a+x "$uphook"
echo "## Enabled by Cogito. It won't try to enable it again as long as this comment is here." >>"$uphook"
fi
fi
or something).
Actually, I might also add something like
[ -e "$_git/git-dummy-support" ] && git-update-server-info
at all the places in Cogito where I update the refs. Then the
default post-update hook could change to
[ -e "$_git/git-dummy-support" ] && exec git-update-server-info
and be enabled by default?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] Fix earlier "import quilt patches" patch
From: Paolo 'Blaisorblade' Giarrusso @ 2005-09-24 10:46 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
I forgot to update all cases - I updated __parse_mail, not __parse_patch, so
refactor together this duplication and use the fixed version.
Btw, I don't like those regexps - they'd match in the middle of line too. What
about adding ^ to their beginning like for the "^Index: " regexp?
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/commands/imprt.py | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/stgit/commands/imprt.py b/stgit/commands/imprt.py
--- a/stgit/commands/imprt.py
+++ b/stgit/commands/imprt.py
@@ -75,6 +75,10 @@ options = [make_option('-m', '--mail',
help = 'use COMMEMAIL as the committer e-mail')]
+def __end_descr(line):
+ return re.match('---\s*$', line) or re.match('diff -', line) or \
+ re.match('^Index: ', line)
+
def __parse_mail(filename = None):
"""Parse the input file in a mail format and return (description,
authname, authemail, authdate)
@@ -116,8 +120,7 @@ def __parse_mail(filename = None):
line = f.readline()
if not line:
break
- if re.match('---\s*$', line) or re.match('diff -', line) or \
- re.match('^Index: ', line):
+ if __end_descr(line):
break
else:
descr += line
@@ -150,7 +153,7 @@ def __parse_patch(filename = None):
auth = re.findall('^.*?:\s+(.*)$', line)[0]
authname, authemail = name_email(auth)
- if re.match('---\s*$', line) or re.match('diff -', line):
+ if __end_descr(line):
break
else:
descr += line
^ permalink raw reply
* [PATCH 3/4] git-daemon --syslog to log through syslog
From: Petr Baudis @ 2005-09-24 14:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050924141254.8423.80265.stgit@machine.or.cz>
Well, this makes it even more clear that we need the packet reader and
friends to use the daemon logging code. :/ Therefore, we at least indicate
in the "Disconnect" log message if the child process exitted with an error
code or not.
Idea by Linus.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-daemon.txt | 6 +++++-
daemon.c | 34 +++++++++++++++++++++++++++-------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -7,7 +7,7 @@ git-daemon - A really simple server for
SYNOPSIS
--------
-'git-daemon' [--verbose] [--inetd | --port=n]
+'git-daemon' [--verbose] [--syslog] [--inetd | --port=n]
DESCRIPTION
-----------
@@ -32,6 +32,10 @@ OPTIONS
--port::
Listen on an alternative port.
+--syslog::
+ Log to syslog instead of stderr. Note that this option does not imply
+ --verbose, thus by default only error conditions will be logged.
+
--verbose::
Log details about the incoming connections and requested files.
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -7,13 +7,15 @@
#include <netdb.h>
#include <netinet/in.h>
#include <arpa/inet.h>
+#include <syslog.h>
+static int log_syslog;
static int verbose;
-static const char daemon_usage[] = "git-daemon [--verbose] [--inetd | --port=n]";
+static const char daemon_usage[] = "git-daemon [--verbose] [--syslog] [--inetd | --port=n]";
-static void logreport(const char *err, va_list params)
+static void logreport(int priority, const char *err, va_list params)
{
/* We should do a single write so that it is atomic and output
* of several processes do not get intermingled. */
@@ -27,6 +29,11 @@ static void logreport(const char *err, v
maxlen = sizeof(buf) - buflen - 1; /* -1 for our own LF */
msglen = vsnprintf(buf + buflen, maxlen, err, params);
+ if (log_syslog) {
+ syslog(priority, "%s", buf);
+ return;
+ }
+
/* maxlen counted our own LF but also counts space given to
* vsnprintf for the terminating NUL. We want to make sure that
* we have space for our own LF and NUL after the "meat" of the
@@ -48,7 +55,7 @@ void logerror(const char *err, ...)
{
va_list params;
va_start(params, err);
- logreport(err, params);
+ logreport(LOG_ERR, err, params);
va_end(params);
}
@@ -58,7 +65,7 @@ void lognotice(const char *err, ...)
if (!verbose)
return;
va_start(params, err);
- logreport(err, params);
+ logreport(LOG_INFO, err, params);
va_end(params);
}
@@ -285,15 +292,23 @@ static void handle(int incoming, struct
static void child_handler(int signo)
{
for (;;) {
- pid_t pid = waitpid(-1, NULL, WNOHANG);
+ int status;
+ pid_t pid = waitpid(-1, &status, WNOHANG);
if (pid > 0) {
unsigned reaped = children_reaped;
dead_child[reaped % MAX_CHILDREN] = pid;
children_reaped = reaped + 1;
/* XXX: Custom logging, since we don't wanna getpid() */
- if (verbose)
- fprintf(stderr, "[%d] Disconnected\n", pid);
+ if (verbose) {
+ char *dead = "";
+ if (!WIFEXITED(status) || WEXITSTATUS(status) > 0)
+ dead = " (with error)";
+ if (log_syslog)
+ syslog(LOG_INFO, "[%d] Disconnected%s", pid, dead);
+ else
+ fprintf(stderr, "[%d] Disconnected%s\n", pid, dead);
+ }
continue;
}
break;
@@ -435,6 +450,11 @@ int main(int argc, char **argv)
verbose = 1;
continue;
}
+ if (!strcmp(arg, "--syslog")) {
+ log_syslog = 1;
+ openlog("git-daemon", 0, LOG_DAEMON);
+ continue;
+ }
usage(daemon_usage);
}
^ permalink raw reply
* [PATCH 0/4] Minor git-daemon enhancements
From: Petr Baudis @ 2005-09-24 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The following series contains some minor git-daemon enhancements,
based on the input from the mailing list.
And I'm also playing with StGIT. ;-)
--
And on the eigth day, God started debugging.
^ permalink raw reply
* [PATCH 2/4] Update git-daemon documentation wrt. the --verbose parameter
From: Petr Baudis @ 2005-09-24 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050924141254.8423.80265.stgit@machine.or.cz>
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-daemon.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -7,7 +7,7 @@ git-daemon - A really simple server for
SYNOPSIS
--------
-'git-daemon' [--inetd | --port=n]
+'git-daemon' [--verbose] [--inetd | --port=n]
DESCRIPTION
-----------
@@ -32,6 +32,9 @@ OPTIONS
--port::
Listen on an alternative port.
+--verbose::
+ Log details about the incoming connections and requested files.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
^ permalink raw reply
* [PATCH 1/4] Fix git-daemon's pid_t logging
From: Petr Baudis @ 2005-09-24 14:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050924141254.8423.80265.stgit@machine.or.cz>
git-daemon's logging code did not properly printf() pid_t - we need
to explicitly typecast it, since it might not be int. Pointed out
by Morten Welinder.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
daemon.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -22,7 +22,7 @@ static void logreport(const char *err, v
int maxlen, msglen;
/* sizeof(buf) should be big enough for "[pid] \n" */
- buflen = snprintf(buf, sizeof(buf), "[%d] ", getpid());
+ buflen = snprintf(buf, sizeof(buf), "[%ld] ", (long) getpid());
maxlen = sizeof(buf) - buflen - 1; /* -1 for our own LF */
msglen = vsnprintf(buf + buflen, maxlen, err, params);
^ permalink raw reply
* [PATCH 4/4] Rename daemon.c's lognotice() to loginfo()
From: Petr Baudis @ 2005-09-24 14:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050924141254.8423.80265.stgit@machine.or.cz>
The syslog code logs with severity LOG_INFO in the loginfo() function, so make
things less confusing.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
daemon.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -59,7 +59,7 @@ void logerror(const char *err, ...)
va_end(params);
}
-void lognotice(const char *err, ...)
+void loginfo(const char *err, ...)
{
va_list params;
if (!verbose)
@@ -72,7 +72,7 @@ void lognotice(const char *err, ...)
static int upload(char *dir, int dirlen)
{
- lognotice("Request for '%s'", dir);
+ loginfo("Request for '%s'", dir);
if (chdir(dir) < 0) {
logerror("Cannot chdir('%s'): %s", dir, strerror(errno));
return -1;
@@ -284,7 +284,7 @@ static void handle(int incoming, struct
port = sin6_addr->sin6_port;
}
- lognotice("Connection from %s:%d", addrbuf, port);
+ loginfo("Connection from %s:%d", addrbuf, port);
exit(execute());
}
^ permalink raw reply
* [ANNOUNCE qgit-0.95]
From: Marco Costalba @ 2005-09-24 16:06 UTC (permalink / raw)
To: git
This is a performance update release.
The detailed list of changes is below, but the bottom line is
qgit-0.95 is _really_ fast.
It tooks about 4 seconds, on my box, to run qgit --all on today linux tree against
about 65 seconds with gitk. Also the used memory it seems lower.
As a 'theoretical maximum speed' a bare:
git-rev-list --header --topo-order --parents HEAD > /dev/null
Runs in about 2 seconds.
So this is the main reason I post this release. I doubt a little bit about this results
because the spread with gitk it seems too much, so I would like a double check.
NOTE: Before to test qgit you need to UNSET flag
edit->settings->cache->'diff against working dir'
to avoid a slow 'git-status' (with involved 'git-update-index --refresh') call.
CHANGELOG
- more scalable pixmap memory handling.
Graph pixmaps are created only for visible items and freed
when log lines became not visible so that the amount of memory
used is constant and independent from archive size. This is also a
performance improvement because of the 'lazy setup' policy.
- changed GUI update policy to group all the updates in one big chunk at
fixed intervals. This is faster then an incremental update.
- more scalable file names handling.
File paths are splitted in base and file name, both are then indipendently
indexed. This gives huge memory savings and also better scalability because the
'different file names' set grows much more slowly then new commits. Using two index
tables gives good memory saving when you have lot of files in the same (deep) directory.
- Rewritten git-rev-list parsing to avoid as much as possible to move data around.
INSTALLATION
You need scons and Qt developer libs version 3.3.4 or better already installed. You need 'mt'
version of Qt libraries.
QGit is NOT compatible with Qt4.
On some platforms (Debian) you should set QTDIR before to compile.
DOWNLOAD
Download link is:
http://prdownloads.sourceforge.net/qgit/qgit-0.95.tar.bz2?download
But now there is also a git archive:
http://digilander.libero.it/mcostalba/qgit.git
Please use 'cg-clone http://digilander.libero.it/mcostalba/qgit.git'
I still have to set-up a 'git clone' friendly archive.
If you have problems with the sources you can download a binary:
http://digilander.libero.it/mcostalba/qgit
Marco
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Daniel Barkalow @ 2005-09-24 17:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20050924125001.GB25069@pasky.or.cz>
On Sat, 24 Sep 2005, Petr Baudis wrote:
> Dear diary, on Sat, Sep 24, 2005 at 04:00:04AM CEST, I got a letter
> where Junio C Hamano <junkio@cox.net> told me that...
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > It takes loooong time, unfortunately - scp -r takes its time itself on
> > > many small files, and then we have to make a separate call to
> > > git-ssh-fetch for each tag. Isn't that braindamaged... :/
> >
> > I think you could run git-peek-remote to find all the refs and
> > then run git-fetch-pack to slurp all the tags (and heads for
> > that matter) at once. Is there a particular reason you would
> > prefer the commit walker?
>
> Actually, probably not, except consistency with rsync and http handling
> - but that's obviously not too good reason. I did it this way since I'm
> going to be a bit busy again from now on.
It wouldn't actually be very hard to rewrite git-*-fetch programs to fetch
with a bunch of starting points. The main reason I haven't is actually
that I don't have any ideas for a way to extend the command line argument
format to include it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: /bin/sh portability question
From: Patrick Mauritz @ 2005-09-24 17:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Eriksen, git
In-Reply-To: <7vmzm4duf8.fsf@assigned-by-dhcp.cox.net>
On Fri, 2005-09-23 at 11:07, Junio C Hamano wrote:
> Good to have a Solaris user. I have one patch that I've been
> keeping in the proposed updates branch, waiting for a
> comfirmation or 'not-good-enough-for-me' answer from people that
> have cURL installed in nonstandard places.
sorry for the lack of reponse.. apart from fixing up context (to match
0.99.7), this patch works here.
thanks,
patrick mauritz
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Linus Torvalds @ 2005-09-24 18:10 UTC (permalink / raw)
To: Davide Libenzi; +Cc: Johannes Schindelin, Peter TB Brett, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509232220330.30718@localhost.localdomain>
On Fri, 23 Sep 2005, Davide Libenzi wrote:
>
> If you have only to run diff/patch, just use the native Win32 CreateProcess().
> You abstract that on a git_exec(), and you use fork/exec on Unix and
> CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is
> pathetic. They do all that work to give you a fork(), and you throw it
> away with an exec().
CreateProcess doesn't work all that well, since we want to dup file
descriptors around and close them in the child.
In general, CreateProcess() is a totally crap interface. I realize it's
common (and especially in the VMS/Windows world it's how things are done),
but hey, at that point it's better if somebody just waits until git is
stable, and just makes a totally separate "git for windows" thing. The
interfaces are certainly simple. There's no point in trying to maintain
one tree.
However, vfork() really _is_ a nice interface. It's faster even on UNIX,
and at least in theory it should be possible to do an efficient vfork()
implementation on top of crap like windows. Does cygwin support that well?
Yes, git uses lots of filesystem stuff, and they suck under windows. Maybe
cygwin adds its own overhead, but from everything I've ever been able to
tell, filesystem access sucks under Windows regardless of any cygwin
stuff. Add to an already slow FS interface the fact that virus checkers
tend to hook into it and make it _even_slower_, and hey, you have a truly
sucky OS.
But at least with pack-files, the filesystem access patterns are much
less common. Opening one pack-file and mapping it gets the FS out of the
way. So I don't think that's necessarily a huge problem.
Linus
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Junio C Hamano @ 2005-09-24 18:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050924125001.GB25069@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> I think you could run git-peek-remote to find all the refs and
>> then run git-fetch-pack to slurp all the tags (and heads for
>> that matter) at once. Is there a particular reason you would
>> prefer the commit walker?
>
> Actually, probably not, except consistency with rsync and http handling
> - but that's obviously not too good reason.
We would end up doing things internally differently between
git-native (fetch/clone-pack) and other protocols (commit walker
which is git-aware, and rsync which is not) anyway.
I misspoke for 'git-fetch-pack' in the above -- git-fetch-pack
without any refspec fetches all the refs, so you do not need a
separate peek-remote. Right now 'git fetch' wrapper does not
let you take advantage of this, but if we wanted to add '--all'
flag to 'git fetch' wrapper, it can be implemented very easily
and efficiently for the git-native protocol. An implementation
of such a flag for other protocols would use git-ls-remote to
find out the refs upfront.
> I will probably rewrite the tags fetching to use git-peek-remote
> (info/refs for http) the next weekend.
If you are targetting multiple protocols, git-ls-remote is the
one to use, not peek-remote. It internally uses peek-remote for
git-native protocol, and emulates it using info/refs for http
and recursive get for rsync, so no new coding on Cogito part
should be necessary.
> default post-update hook could change to
>
> [ -e "$_git/git-dummy-support" ] && exec git-update-server-info
>
> and be enabled by default?
That is a thought. While I think doing update-server-info
everywhere whenever you update ref is going a bit overboard, I
agree there should be an easy way for the end user to keep
repositories that are public accessible all times. But running
server-info upon every commit does not make much sense to me --
something is seriously broken if we need to do that.
Cases when you would want to make your repository accessible
from outside itself varies and preferred transport obviously
depends on it.
- Your private working area. Typically does not allow
anonymous downloads. You are the only one to use git tools
and compilation there (that's what 'private' means).
- A CVS style shared repository. May allow anonymous
downloads, and allow uploads to people with 'commit
privilege' in CVS lingo.
- A public distribution point, like kernel.org repository.
This is just a special case of the 'shared repository' above,
with yourself as the only uploader.
I thought there would be more classes, but it really boils down
to whether you would allow anonymous downloads or not -- so
let's call them private and public.
Fetching over non git-native protocol is the only case where
server-info matters; so obviously it is nicer if public
repository is arranged so that update-server-info is run
everytime refs and set of packs change.
I do not think of a good reason not to use git-aware protocol
when one is fetching from a private repo -- so if we just say
people should not use non git-aware protocol when doing so, we
do not have to do server-info in the private repositories at
all.
So the question is, how often do we need to run update to keep
the refs and set of packs in public repository in sync with the
server-info. What do people do in public repository to affect
set of packs and the refs?
- Initiate a push into it from somewhere else; this case is
covered by enabling post-update hook.
- You log on to the machine of public repository and run 'git
repack'; this runs update-server-info, so it is OK.
- You log on to the machine of public repository and run fetch
of another repository -- you may even end up hand merging and
creating new commits.
- You log on to the machine of public repository and do your
development, making your own commits.
It is the latter two cases where your 'update-server-info
everywhere in Cogito' would be needed -- but is it realistic?
^ permalink raw reply
* Re: [ANNOUNCE qgit-0.95]
From: Petr Baudis @ 2005-09-24 18:16 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050924160641.60151.qmail@web26307.mail.ukl.yahoo.com>
Dear diary, on Sat, Sep 24, 2005 at 06:06:40PM CEST, I got a letter
where Marco Costalba <mcostalba@yahoo.it> told me that...
> This is a performance update release.
>
> The detailed list of changes is below, but the bottom line is
> qgit-0.95 is _really_ fast.
>
> It tooks about 4 seconds, on my box, to run qgit --all on today linux tree against
> about 65 seconds with gitk. Also the used memory it seems lower.
>
> As a 'theoretical maximum speed' a bare:
>
> git-rev-list --header --topo-order --parents HEAD > /dev/null
>
> Runs in about 2 seconds.
>
> So this is the main reason I post this release. I doubt a little bit about this results
> because the spread with gitk it seems too much, so I would like a double check.
Yes, it is several times faster than gitk, good work. Had to do this in
order to be able to compile it with gcc-3.3.6, though (it complained
about goto'ing after initialization of nc - that's bogus since there's
the return, but...):
diff --git a/src/git_startup.cpp b/src/git_startup.cpp
--- a/src/git_startup.cpp
+++ b/src/git_startup.cpp
@@ -469,7 +469,9 @@ again:
if (!resumeTimer.isActive())
resumeTimer.start(1, true); // with 0 ms there is an oops in libqt-mt
return; // we suspend here to let GUI updating
+ }
+ if (false) {
resume:
suspended = false;
processTime.start();
Besides that, this is what I don't like about qgit:
* It'd be nice to be able to choose to see all commits in the initial
dialog by single click (I know about --all). Perhaps a radio buttons
choosing between all and selected? Also, you might add the "diff against
working copy" option to that dialog as well.
* The graph column is too narrow. It should be auto-sized so that the
graph fits in, or at least there should be some clear indication that
the graph does not fit to the column at the given point. This confused
me a lot at first.
* Could you make the grey background for odd commits span to the whole
line, including the commit graph?
* The commit time is relative to now, which makes no sense to me. Also,
it is in the second column instead of the last one like in gitk, which
seems better to me. At least, the column is too narrow and then it
blends together with the commit title.
* In the filter radio buttons groups, only first few letters of the
labels are visible, and apparently no tooltips. Same problem in the
settings dialog, most of the options have the labels cut around 2/3, and
the window is non-resizable on top of that - why? I hate non-resizable
windows, especially because they are usually too small. :-)
* Single-clicking at a commit produces a significantly slower response
than in gitk, where I see the difflist and stuff nearly instantly - it
takes several hundreds of ms in qgit. That's quite annoying.
* Getting to the diff view was non-obvious for me. It'd be nice to have
some [diff] button as well somewhere. Or you could also show the diff in
the bottom part of screen in the commit view, I think gitk solved this
nicely.
* Clicking on the file was supposed to bring some annotated view, but if
it is so, it should write "Annotate" in the window title, and should
indicate that it is computing it on the background (and is really slow
in that, or I don't know, but always only single revision was shown
there). It is unclear what the "pin file" checkbox is supposed to mean,
and the whole dialog is just very confusing. :-)
* The lane information might be available as a tooltip in addition to
right-clicking on it - that wouldn't occur to me.
* Why is the Edit menu aligned to the right?
* Well - I don't like the line graphics and prefer gitk's. This is
perhaps a matter of taste, though. I find the graphics to be too tiny,
thin and not so clear as gitk's, which makes it harder to see the commit
flow. I also like diagonal lines more than angles, but that might be
just because I'm used to them.
OTOH, qgit actually flows the commits around the 0.99.6 release and such
better than gitk, keeping them all in a single lane instead of flowing
off to the right. It is still a bit hard to see what actually went on,
but curing that would require sorting the commits by date.
Nice work otherwise. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: git 0.99.7b doesn't build on Cygwin
From: Davide Libenzi @ 2005-09-24 19:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Peter TB Brett, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509241102450.3308@g5.osdl.org>
On Sat, 24 Sep 2005, Linus Torvalds wrote:
>
>
> On Fri, 23 Sep 2005, Davide Libenzi wrote:
>>
>> If you have only to run diff/patch, just use the native Win32 CreateProcess().
>> You abstract that on a git_exec(), and you use fork/exec on Unix and
>> CreateProcess() on Winblows. If fork() is slow on Cygwin, fork+exec is
>> pathetic. They do all that work to give you a fork(), and you throw it
>> away with an exec().
>
> CreateProcess doesn't work all that well, since we want to dup file
> descriptors around and close them in the child.
You can do that (dup stuff and pass them around) even with CreateProcess(),
if you want. Yes, the interface sucks (zillions of parameters/flags) ;)
> In general, CreateProcess() is a totally crap interface. I realize it's
> common (and especially in the VMS/Windows world it's how things are done),
> but hey, at that point it's better if somebody just waits until git is
> stable, and just makes a totally separate "git for windows" thing. The
> interfaces are certainly simple. There's no point in trying to maintain
> one tree.
>
> However, vfork() really _is_ a nice interface. It's faster even on UNIX,
> and at least in theory it should be possible to do an efficient vfork()
> implementation on top of crap like windows. Does cygwin support that well?
>
> Yes, git uses lots of filesystem stuff, and they suck under windows. Maybe
> cygwin adds its own overhead, but from everything I've ever been able to
> tell, filesystem access sucks under Windows regardless of any cygwin
> stuff. Add to an already slow FS interface the fact that virus checkers
> tend to hook into it and make it _even_slower_, and hey, you have a truly
> sucky OS.
I also realized that git plays/handles with unix permissions too, and this
might make the "interface layer" not so small. Dunno about vfork() on
Cygwin, but if you really care about performance on Windows, I'd rather
remove the external program execution and use an in-process diff library.
- Davide
^ permalink raw reply
* Re: [PATCH] Fix earlier "import quilt patches" patch
From: Catalin Marinas @ 2005-09-24 19:47 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20050924104622.17274.18611.stgit@zion.home.lan>
On 24/09/05, Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> wrote:
> I forgot to update all cases - I updated __parse_mail, not __parse_patch, so
> refactor together this duplication and use the fixed version.
Thanks. I'll apply it tomorrow.
> Btw, I don't like those regexps - they'd match in the middle of line too. What
> about adding ^ to their beginning like for the "^Index: " regexp?
Python's re.match() only matches from the beginning of the line, so ^
is not needed.
Catalin
--
Catalin
^ 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