* Cannot git pull using http from my git.mycompany.com
From: Gary Yang @ 2008-11-21 1:13 UTC (permalink / raw)
To: git
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Below are related gitweb configs. What did I do wrong?
httpd.confg
<VirtualHost 10.66.4.168>
ServerName svdcgit01
DocumentRoot /pub/git
<Directory /var/www/cgi-bin>
Allow from all
AllowOverride all
Order allow,deny
Options ExecCGI
<Files gitweb.cgi>
SetHandler cgi-script
</Files>
</Directory>
DirectoryIndex /cgi-bin/gitweb.cgi
SetEnv GITWEB_CONFIG /etc/gitweb.conf
# RewriteEngine on
# RewriteRule ^/(.*\.git/(?!/?(HEAD|info|objects|refs)).*)?$ /cgi-bin/gitweb.cgi%{REQUEST_URI} [L,PT]
cat /etc/gitweb.conf
# path to git projects (<project>.git)
$projectroot = "/pub/git";
# directory to use for temp files
$git_temp = "/tmp";
# target of the home link on top of all pages
$home_link = $my_uri;
# html text to include at home page
$home_text = "indextext.html";
# file with project list; by default, simply scan the projectroot dir.
$projects_list = $projectroot;
# stylesheet to use
$stylesheet = "/gitweb/gitweb.css";
# logo to use
#$logo = "/git-logo.png";
$logo = "/gitweb/git-logo.png";
# the 'favicon'
$favicon = "/gitweb/git-favicon.png";
$projects_list_description_width = 60;
#$feature{'pathinfo'}{'default'} = [1];
^ permalink raw reply
* [PATCH 3/4] builtin-clone: use strbuf in clone_local() and copy_or_link_directory()
From: Miklos Vajna @ 2008-11-21 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1227227976.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-clone.c | 58 +++++++++++++++++++++++++++++-------------------------
1 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 52b1242..8182ebd 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -183,36 +183,38 @@ static void setup_reference(const char *repo)
free(ref_git_copy);
}
-static void copy_or_link_directory(char *src, char *dest)
+static void copy_or_link_directory(struct strbuf *src, struct strbuf *dest)
{
struct dirent *de;
struct stat buf;
int src_len, dest_len;
DIR *dir;
- dir = opendir(src);
+ dir = opendir(src->buf);
if (!dir)
- die("failed to open %s\n", src);
+ die("failed to open %s\n", src->buf);
- if (mkdir(dest, 0777)) {
+ if (mkdir(dest->buf, 0777)) {
if (errno != EEXIST)
- die("failed to create directory %s\n", dest);
- else if (stat(dest, &buf))
- die("failed to stat %s\n", dest);
+ die("failed to create directory %s\n", dest->buf);
+ else if (stat(dest->buf, &buf))
+ die("failed to stat %s\n", dest->buf);
else if (!S_ISDIR(buf.st_mode))
- die("%s exists and is not a directory\n", dest);
+ die("%s exists and is not a directory\n", dest->buf);
}
- src_len = strlen(src);
- src[src_len] = '/';
- dest_len = strlen(dest);
- dest[dest_len] = '/';
+ strbuf_addch(src, '/');
+ src_len = src->len;
+ strbuf_addch(dest, '/');
+ dest_len = dest->len;
while ((de = readdir(dir)) != NULL) {
- strcpy(src + src_len + 1, de->d_name);
- strcpy(dest + dest_len + 1, de->d_name);
- if (stat(src, &buf)) {
- warning ("failed to stat %s\n", src);
+ strbuf_setlen(src, src_len);
+ strbuf_addstr(src, de->d_name);
+ strbuf_setlen(dest, dest_len);
+ strbuf_addstr(dest, de->d_name);
+ if (stat(src->buf, &buf)) {
+ warning ("failed to stat %s\n", src->buf);
continue;
}
if (S_ISDIR(buf.st_mode)) {
@@ -221,17 +223,17 @@ static void copy_or_link_directory(char *src, char *dest)
continue;
}
- if (unlink(dest) && errno != ENOENT)
- die("failed to unlink %s\n", dest);
+ if (unlink(dest->buf) && errno != ENOENT)
+ die("failed to unlink %s\n", dest->buf);
if (!option_no_hardlinks) {
- if (!link(src, dest))
+ if (!link(src->buf, dest->buf))
continue;
if (option_local)
- die("failed to create link %s\n", dest);
+ die("failed to create link %s\n", dest->buf);
option_no_hardlinks = 1;
}
- if (copy_file(dest, src, 0666))
- die("failed to copy file to %s\n", dest);
+ if (copy_file(dest->buf, src->buf, 0666))
+ die("failed to copy file to %s\n", dest->buf);
}
closedir(dir);
}
@@ -240,17 +242,19 @@ static const struct ref *clone_local(const char *src_repo,
const char *dest_repo)
{
const struct ref *ret;
- char src[PATH_MAX];
- char dest[PATH_MAX];
+ struct strbuf src = STRBUF_INIT;
+ struct strbuf dest = STRBUF_INIT;
struct remote *remote;
struct transport *transport;
if (option_shared)
add_to_alternates_file(src_repo);
else {
- snprintf(src, PATH_MAX, "%s/objects", src_repo);
- snprintf(dest, PATH_MAX, "%s/objects", dest_repo);
- copy_or_link_directory(src, dest);
+ strbuf_addf(&src, "%s/objects", src_repo);
+ strbuf_addf(&dest, "%s/objects", dest_repo);
+ copy_or_link_directory(&src, &dest);
+ strbuf_release(&src);
+ strbuf_release(&dest);
}
remote = remote_get(src_repo);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/4] builtin_clone: use strbuf in cmd_clone()
From: Miklos Vajna @ 2008-11-21 0:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1227227976.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-clone.c | 45 +++++++++++++++++++++++++--------------------
1 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 8182ebd..a6ea3d6 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -358,8 +358,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- char branch_top[256], key[256], value[256];
- struct strbuf reflog_msg = STRBUF_INIT;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -463,35 +463,36 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_bare) {
if (option_mirror)
src_ref_prefix = "refs/";
- strcpy(branch_top, src_ref_prefix);
+ strbuf_addstr(&branch_top, src_ref_prefix);
git_config_set("core.bare", "true");
} else {
- snprintf(branch_top, sizeof(branch_top),
- "refs/remotes/%s/", option_origin);
+ strbuf_addf(&branch_top, "refs/remotes/%s/", option_origin);
}
if (option_mirror || !option_bare) {
/* Configure the remote */
if (option_mirror) {
- snprintf(key, sizeof(key),
- "remote.%s.mirror", option_origin);
- git_config_set(key, "true");
+ strbuf_addf(&key, "remote.%s.mirror", option_origin);
+ git_config_set(key.buf, "true");
+ strbuf_reset(&key);
}
- snprintf(key, sizeof(key), "remote.%s.url", option_origin);
- git_config_set(key, repo);
+ strbuf_addf(&key, "remote.%s.url", option_origin);
+ git_config_set(key.buf, repo);
+ strbuf_reset(&key);
- snprintf(key, sizeof(key), "remote.%s.fetch", option_origin);
- snprintf(value, sizeof(value),
- "+%s*:%s*", src_ref_prefix, branch_top);
- git_config_set_multivar(key, value, "^$", 0);
+ strbuf_addf(&key, "remote.%s.fetch", option_origin);
+ strbuf_addf(&value, "+%s*:%s*", src_ref_prefix, branch_top.buf);
+ git_config_set_multivar(key.buf, value.buf, "^$", 0);
+ strbuf_reset(&key);
+ strbuf_reset(&value);
}
refspec.force = 0;
refspec.pattern = 1;
refspec.src = src_ref_prefix;
- refspec.dst = branch_top;
+ refspec.dst = branch_top.buf;
if (path && !is_bundle)
refs = clone_local(path, git_dir);
@@ -546,7 +547,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
head_points_at->old_sha1,
NULL, 0, DIE_ON_ERR);
- strbuf_addstr(&head_ref, branch_top);
+ strbuf_addstr(&head_ref, branch_top.buf);
strbuf_addstr(&head_ref, "HEAD");
/* Remote branch link */
@@ -554,10 +555,11 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
head_points_at->peer_ref->name,
reflog_msg.buf);
- snprintf(key, sizeof(key), "branch.%s.remote", head);
- git_config_set(key, option_origin);
- snprintf(key, sizeof(key), "branch.%s.merge", head);
- git_config_set(key, head_points_at->name);
+ strbuf_addf(&key, "branch.%s.remote", head);
+ git_config_set(key.buf, option_origin);
+ strbuf_reset(&key);
+ strbuf_addf(&key, "branch.%s.merge", head);
+ git_config_set(key.buf, head_points_at->name);
}
} else if (remote_head) {
/* Source had detached HEAD pointing somewhere. */
@@ -607,6 +609,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
strbuf_release(&reflog_msg);
+ strbuf_release(&branch_top);
+ strbuf_release(&key);
+ strbuf_release(&value);
junk_pid = 0;
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/4] builtin-clone: fix a memory leak in cmd_clone()
From: Miklos Vajna @ 2008-11-21 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1227227976.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-clone.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 8e1a1d3..da21cab 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -516,6 +516,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = transport_get_remote_refs(transport);
transport_fetch_refs(transport, refs);
}
+ free(dir);
clear_extra_refs();
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/4] builtin-clone: use strbuf in guess_dir_name()
From: Miklos Vajna @ 2008-11-21 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <cover.1227227976.git.vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-clone.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index da21cab..52b1242 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -134,9 +134,9 @@ static char *guess_dir_name(const char *repo, int is_bundle, int is_bare)
}
if (is_bare) {
- char *result = xmalloc(end - start + 5);
- sprintf(result, "%.*s.git", (int)(end - start), start);
- return result;
+ struct strbuf result = STRBUF_INIT;
+ strbuf_addf(&result, "%.*s.git", (int)(end - start), start);
+ return strbuf_detach(&result, 0);
}
return xstrndup(start, end - start);
--
1.6.0.4
^ permalink raw reply related
* [PATCH 0/4] builtin-clone: use strbuf
From: Miklos Vajna @ 2008-11-21 0:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
These patches replace hand-rolled sprintf/strcpy usage and such with
using the strbuf API.
The first patch is unrelated, I just noticed that minor issue during
creating the other patches.
Miklos Vajna (4):
builtin-clone: fix a memory leak in cmd_clone()
builtin-clone: use strbuf in guess_dir_name()
builtin-clone: use strbuf in clone_local() and
copy_or_link_directory()
builtin_clone: use strbuf in cmd_clone()
builtin-clone.c | 110 ++++++++++++++++++++++++++++++-------------------------
1 files changed, 60 insertions(+), 50 deletions(-)
^ permalink raw reply
* Re: Bad git status performance
From: David Bryson @ 2008-11-21 0:42 UTC (permalink / raw)
To: Jean-Luc Herren; +Cc: Git Mailing List
In-Reply-To: <4926009E.4040203@gmx.ch>
Hi,
On Fri, Nov 21, 2008 at 01:28:14AM +0100 or thereabouts, Jean-Luc Herren wrote:
> Hi list!
>
> I'm getting bad performance on 'git status' when I have staged
> many changes to big files. For example, consider this:
>
[snip]
> $ time git status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> #
> # modified: 1
> # modified: 10
> ...
> # modified: 98
> # modified: 99
> #
>
> real 0m16.291s
> user 0m16.054s
> sys 0m0.221s
>
> The first 'git status' shows the same difference as the second,
> just the second time it's staged instead of unstaged. Why does it
> take 16 seconds the second time when it's instant the first time?
I had similar problems with a repository that contained several tarballs
of gcc and the linux kernel(don't ask me why it was not my repository).
Some weeks ago I mentioned this on IRC, and the problem really was not
necessarily git. The way it was explained to me(and please correct or
clairify where I am wrong) is that git asked linux for the status of
those files and being that they are so large they were swapped out of
memory.
The result is the kernel reading those large files back in to see if
they have changed at all. My impression is that this is not a git bug
but a cache-tuning problem.
Dave
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-21 0:39 UTC (permalink / raw)
To: J.H.; +Cc: Deskin Miller, git
In-Reply-To: <563817.77498.qm@web37903.mail.mud.yahoo.com>
I killed xinetd. Restarted with sudo xinetd -stayalive -pidfile /var/run/xinetd.pid.
I back to my private box. I did
git pull git://git.mycompany.com/pub/git/u-boot.git HEAD
This command hangs for over half hour and is still hanging. Again, below is the content of /etc/xinetd.d/git-daemon. What I did wrong?
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = git-daemon --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
--- On Thu, 11/20/08, Gary Yang <garyyang6@yahoo.com> wrote:
> From: Gary Yang <garyyang6@yahoo.com>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "J.H." <warthog19@eaglescrag.net>
> Cc: "Deskin Miller" <deskinm@umich.edu>, git@vger.kernel.org
> Date: Thursday, November 20, 2008, 4:14 PM
> Kill the process, then
>
> sudo xinetd -stayalive -pidfile /var/run/xinetd.pid
>
> Please let me know if it is correct. Thanks.
>
>
> --- On Thu, 11/20/08, Gary Yang <garyyang6@yahoo.com>
> wrote:
>
> > From: Gary Yang <garyyang6@yahoo.com>
> > Subject: Re: Challenge of setting up git server
> (repository). Please help!
> > To: "J.H." <warthog19@eaglescrag.net>
> > Cc: "Deskin Miller"
> <deskinm@umich.edu>, git@vger.kernel.org
> > Date: Thursday, November 20, 2008, 4:12 PM
> > I am not system admin. How to restart it? Can I do
> this?
> >
> > sudo xinetd -stayalive -pidfile /var/run/xinetd.pid
> >
> >
> > Below is the output of current running xinetd
> >
> > ps -efww | grep xinetd
> > root 8874 1 0 Sep24 ? 00:00:00 xinetd
> > -stayalive -pidfile /var/run/xinetd.pid
> >
> >
> > Thanks.
> >
> >
> > --- On Thu, 11/20/08, J.H.
> <warthog19@eaglescrag.net>
> > wrote:
> >
> > > From: J.H. <warthog19@eaglescrag.net>
> > > Subject: Re: Challenge of setting up git server
> > (repository). Please help!
> > > To: garyyang6@yahoo.com
> > > Cc: "Deskin Miller"
> > <deskinm@umich.edu>, git@vger.kernel.org
> > > Date: Thursday, November 20, 2008, 3:59 PM
> > > Yes.
> > >
> > > - John 'Warthog9' Hawley
> > > Chief Kernel.org Administrator
> > >
> > >
> > > On Thu, 2008-11-20 at 15:54 -0800, Gary Yang
> wrote:
> > > > Do I need to restart xinetd after I made
> changes
> > in
> > > /etc/xinetd.d/git-daemon?
> > > >
> > > >
> > > > --- On Thu, 11/20/08, Gary Yang
> > > <garyyang6@yahoo.com> wrote:
> > > >
> > > > > From: Gary Yang
> <garyyang6@yahoo.com>
> > > > > Subject: Re: Challenge of setting up
> git
> > server
> > > (repository). Please help!
> > > > > To: "Deskin Miller"
> > > <deskinm@umich.edu>
> > > > > Cc: git@vger.kernel.org
> > > > > Date: Thursday, November 20, 2008, 3:48
> PM
> > > > > I ran the command,"sudo
> > > > > /usr/local/libexec/git-core/git-daemon
> > git-daemon
> > > > > --export-all /pub/git &" at
> public
> > > repository
> > > > > machine.
> > > > >
> > > > > At my private machine, I ran, git pull
> > > > >
> git://svdcgit01.amcc.com/pub/git/u-boot.git
> > > HEAD"
> > > > >
> > > > > I got: "fatal: The remote end hung
> up
> > > > > unexpectedly"
> > > > >
> > > > > At the public repository server, I got
> > > > > "'/pub/git/u-boot.git':
> > repository
> > > not
> > > > > exported." Any idea of this error?
> > > > >
> > > > >
> > > > > ps -A | grep inetd
> > > > > 8874 ? 00:00:00 xinetd
> > > > >
> > > > > It means it uses xinetd.
> > > > >
> > > > > I copied git-daemon back to
> /etc/xinetd.d
> > and
> > > added
> > > > > git-daemon to the server_args. See
> below:
> > > > >
> > > > > cat /etc/xinetd.d/git-daemon
> > > > > # default: off
> > > > > # description: The git server offers
> access
> > to
> > > git
> > > > > repositories
> > > > > service git
> > > > > {
> > > > > disable = no
> > > > > type = UNLISTED
> > > > > port = 9418
> > > > > socket_type = stream
> > > > > wait = no
> > > > > user = nobody
> > > > > server =
> > > > > /usr/local/libexec/git-core/git-daemon
> > > > > server_args = git-daemon
> --inetd
> > > --export-all
> > > > > --base-path=/pub/git
> > > > > log_on_failure += USERID
> > > > > }
> > > > >
> > > > >
> > > > > I kill the daemon
> > > > >
> "/usr/local/libexec/git-core/git-daemon
> > > git-daemon
> > > > > --export-all /pub/git &".
> > > > >
> > > > > Back to my private box, and did git
> pull. I
> > got
> > > Connection
> > > > > refused again. what I did wrong?
> > > > >
> > > > > git pull
> > > git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
> > > > > svdcgit01.amcc.com[0: 10.66.4.168]:
> > > errno=Connection
> > > > > refused
> > > > > fatal: unable to connect a socket
> > (Connection
> > > refused)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --- On Thu, 11/20/08, Deskin Miller
> > > > > <deskinm@umich.edu> wrote:
> > > > >
> > > > > > From: Deskin Miller
> > > <deskinm@umich.edu>
> > > > > > Subject: Re: Challenge of setting
> up
> > git
> > > server
> > > > > (repository). Please help!
> > > > > > To: "Gary Yang"
> > > <garyyang6@yahoo.com>
> > > > > > Cc: git@vger.kernel.org
> > > > > > Date: Thursday, November 20, 2008,
> 3:08
> > PM
> > > > > > On Thu, Nov 20, 2008 at 02:43:30PM
> > -0800,
> > > Gary Yang
> > > > > wrote:
> > > > > > > Many thanks for your
> explanation.
> > I
> > > hope I
> > > > > understand
> > > > > > what you said. I deleted
> > > /etc/xinetd.d/git-daemon.
> > > > > Then, I
> > > > > > tried to git pull. But, I got
> > connection
> > > refused. git
> > > > > uses
> > > > > > port 9418. Should I request IT
> Admin to
> > open
> > > the port
> > > > > 9418
> > > > > > for me?
> > > > > >
> > > > > > You'll need port 9418 open,
> yes;
> > but
> > > since
> > > > > it's an
> > > > > > unprivileged port (1024 or
> > > > > > higher), you can use it as a
> regular
> > user
> > > and
> > > > > don't
> > > > > > need IT intervention unless you
> have
> > some
> > > firewall set
> > > > > up
> > > > > > which they need to override for
> you.
> > > > > >
> > > > > > > git pull
> > > > >
> git://git.mycompany.com/pub/git/u-boot.git
> > > > > > HEAD
> > > > > > > git.mycompany.com[0:
> 10.66.4.168]:
> > > > > errno=Connection
> > > > > > refused
> > > > > > > fatal: unable to connect a
> socket
> > > (Connection
> > > > > refused)
> > > > > >
> > > > > > It's possible, and likely
> simpler,
> > to
> > > use
> > > > > git-daemon
> > > > > > directly, instead of
> > > > > > having it be managed by inetd;
> > especially
> > > for initial
> > > > > > debugging, I'd recommend
> > > > > > getting that working before trying
> to
> > > determine if
> > > > > > you're having issues with
> > > > > > inetd configuration: to do so,
> just run
> > > git-daemon
> > > > > with all
> > > > > > the same arguments
> > > > > > except for --inetd.
> > > > > >
> > > > > > You said you deleted the xinetd
> config,
> > but
> > > that's
> > > > > only
> > > > > > relevant if your
> > > > > > machine actually uses inetd as its
> > > super-server. You
> > > > > > should do 'ps -A | grep
> > > > > > inetd' (which will match
> either
> > inetd or
> > > xinetd),
> > > > > and
> > > > > > see which one is running.
> > > > > > If it's inetd, you should be
> all
> > set,
> > > and the
> > > > > issue
> > > > > > doesn't look like inetd
> > > > > > (assuming you sent it a signal to
> > reload its
> > > config
> > > > > file).
> > > > > > If on the other
> > > > > > hand xinetd is running, you need
> to use
> > the
> > > xinetd
> > > > > config
> > > > > > file, and fix the
> > > > > > server_args to look like the
> arguments
> > which
> > > exist in
> > > > > the
> > > > > > inetd file. Again,
> > > > > > you need to signal xinetd at this
> point
> > to
> > > reload its
> > > > > > configuration.
> > > > > >
> > > > > > Based on the linux kernel version
> > you're
> > > > > reporting,
> > > > > > I'm guessing you have some
> > > > > > sort of Red Hat based system,
> which
> > uses
> > > xinetd to the
> > > > > best
> > > > > > of my knowledge.
> > > > > >
> > > > > > > Another question, I got no
> output
> > of
> > > > > "netstat |
> > > > > > grep 9418". It means no
> program
> > runs at
> > > port 9418
> > > > > at
> > > > > > the public repository machine. Is
> it
> > > correct?
> > > > > > >
> > > > > > > netstat | grep 9418
> > > > > >
> > > > > > netstat translates IP addresses to
> dns
> > > names, and
> > > > > ports to
> > > > > > service names by
> > > > > > default; so, given the line listed
> in
> > > /etc/services,
> > > > > this
> > > > > > will show
> > > > > > '0.0.0.0:git' or
> something.
> > Also,
> > > it lists
> > > > > > established connections, not
> > > > > > listening sockets, by default.
> I'd
> > > recommend
> > > > > spending
> > > > > > some time with the man
> > > > > > page if you're going to use it
> to
> > debug
> > > your
> > > > > setup.
> > > > > >
> > > > > > Deskin Miller
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > > --
> > > 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
>
>
>
> --
> 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
* Bad git status performance
From: Jean-Luc Herren @ 2008-11-21 0:28 UTC (permalink / raw)
To: Git Mailing List
Hi list!
I'm getting bad performance on 'git status' when I have staged
many changes to big files. For example, consider this:
$ git init
Initialized empty Git repository in $HOME/test/.git/
$ for X in $(seq 100); do dd if=/dev/zero of=$X bs=1M count=1 2> /dev/null; done
$ git add .
$ git commit -m 'Lots of zeroes'
Created initial commit ed54346: Lots of zeroes
100 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 1
create mode 100644 10
...
create mode 100644 98
create mode 100644 99
$ for X in $(seq 100); do echo > $X; done
$ time git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: 1
# modified: 10
...
# modified: 98
# modified: 99
#
no changes added to commit (use "git add" and/or "git commit -a")
real 0m0.003s
user 0m0.001s
sys 0m0.002s
$ git add -u
$ time git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: 1
# modified: 10
...
# modified: 98
# modified: 99
#
real 0m16.291s
user 0m16.054s
sys 0m0.221s
The first 'git status' shows the same difference as the second,
just the second time it's staged instead of unstaged. Why does it
take 16 seconds the second time when it's instant the first time?
(Side note: There once was a discussion about adding natural order
of branch names, but seems it never made it into git. The same
would make sense for 'git status' too.)
Cheers,
jlh
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-21 0:14 UTC (permalink / raw)
To: J.H.; +Cc: Deskin Miller, git
Kill the process, then
sudo xinetd -stayalive -pidfile /var/run/xinetd.pid
Please let me know if it is correct. Thanks.
--- On Thu, 11/20/08, Gary Yang <garyyang6@yahoo.com> wrote:
> From: Gary Yang <garyyang6@yahoo.com>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "J.H." <warthog19@eaglescrag.net>
> Cc: "Deskin Miller" <deskinm@umich.edu>, git@vger.kernel.org
> Date: Thursday, November 20, 2008, 4:12 PM
> I am not system admin. How to restart it? Can I do this?
>
> sudo xinetd -stayalive -pidfile /var/run/xinetd.pid
>
>
> Below is the output of current running xinetd
>
> ps -efww | grep xinetd
> root 8874 1 0 Sep24 ? 00:00:00 xinetd
> -stayalive -pidfile /var/run/xinetd.pid
>
>
> Thanks.
>
>
> --- On Thu, 11/20/08, J.H. <warthog19@eaglescrag.net>
> wrote:
>
> > From: J.H. <warthog19@eaglescrag.net>
> > Subject: Re: Challenge of setting up git server
> (repository). Please help!
> > To: garyyang6@yahoo.com
> > Cc: "Deskin Miller"
> <deskinm@umich.edu>, git@vger.kernel.org
> > Date: Thursday, November 20, 2008, 3:59 PM
> > Yes.
> >
> > - John 'Warthog9' Hawley
> > Chief Kernel.org Administrator
> >
> >
> > On Thu, 2008-11-20 at 15:54 -0800, Gary Yang wrote:
> > > Do I need to restart xinetd after I made changes
> in
> > /etc/xinetd.d/git-daemon?
> > >
> > >
> > > --- On Thu, 11/20/08, Gary Yang
> > <garyyang6@yahoo.com> wrote:
> > >
> > > > From: Gary Yang <garyyang6@yahoo.com>
> > > > Subject: Re: Challenge of setting up git
> server
> > (repository). Please help!
> > > > To: "Deskin Miller"
> > <deskinm@umich.edu>
> > > > Cc: git@vger.kernel.org
> > > > Date: Thursday, November 20, 2008, 3:48 PM
> > > > I ran the command,"sudo
> > > > /usr/local/libexec/git-core/git-daemon
> git-daemon
> > > > --export-all /pub/git &" at public
> > repository
> > > > machine.
> > > >
> > > > At my private machine, I ran, git pull
> > > > git://svdcgit01.amcc.com/pub/git/u-boot.git
> > HEAD"
> > > >
> > > > I got: "fatal: The remote end hung up
> > > > unexpectedly"
> > > >
> > > > At the public repository server, I got
> > > > "'/pub/git/u-boot.git':
> repository
> > not
> > > > exported." Any idea of this error?
> > > >
> > > >
> > > > ps -A | grep inetd
> > > > 8874 ? 00:00:00 xinetd
> > > >
> > > > It means it uses xinetd.
> > > >
> > > > I copied git-daemon back to /etc/xinetd.d
> and
> > added
> > > > git-daemon to the server_args. See below:
> > > >
> > > > cat /etc/xinetd.d/git-daemon
> > > > # default: off
> > > > # description: The git server offers access
> to
> > git
> > > > repositories
> > > > service git
> > > > {
> > > > disable = no
> > > > type = UNLISTED
> > > > port = 9418
> > > > socket_type = stream
> > > > wait = no
> > > > user = nobody
> > > > server =
> > > > /usr/local/libexec/git-core/git-daemon
> > > > server_args = git-daemon --inetd
> > --export-all
> > > > --base-path=/pub/git
> > > > log_on_failure += USERID
> > > > }
> > > >
> > > >
> > > > I kill the daemon
> > > > "/usr/local/libexec/git-core/git-daemon
> > git-daemon
> > > > --export-all /pub/git &".
> > > >
> > > > Back to my private box, and did git pull. I
> got
> > Connection
> > > > refused again. what I did wrong?
> > > >
> > > > git pull
> > git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
> > > > svdcgit01.amcc.com[0: 10.66.4.168]:
> > errno=Connection
> > > > refused
> > > > fatal: unable to connect a socket
> (Connection
> > refused)
> > > >
> > > >
> > > >
> > > >
> > > > --- On Thu, 11/20/08, Deskin Miller
> > > > <deskinm@umich.edu> wrote:
> > > >
> > > > > From: Deskin Miller
> > <deskinm@umich.edu>
> > > > > Subject: Re: Challenge of setting up
> git
> > server
> > > > (repository). Please help!
> > > > > To: "Gary Yang"
> > <garyyang6@yahoo.com>
> > > > > Cc: git@vger.kernel.org
> > > > > Date: Thursday, November 20, 2008, 3:08
> PM
> > > > > On Thu, Nov 20, 2008 at 02:43:30PM
> -0800,
> > Gary Yang
> > > > wrote:
> > > > > > Many thanks for your explanation.
> I
> > hope I
> > > > understand
> > > > > what you said. I deleted
> > /etc/xinetd.d/git-daemon.
> > > > Then, I
> > > > > tried to git pull. But, I got
> connection
> > refused. git
> > > > uses
> > > > > port 9418. Should I request IT Admin to
> open
> > the port
> > > > 9418
> > > > > for me?
> > > > >
> > > > > You'll need port 9418 open, yes;
> but
> > since
> > > > it's an
> > > > > unprivileged port (1024 or
> > > > > higher), you can use it as a regular
> user
> > and
> > > > don't
> > > > > need IT intervention unless you have
> some
> > firewall set
> > > > up
> > > > > which they need to override for you.
> > > > >
> > > > > > git pull
> > > > git://git.mycompany.com/pub/git/u-boot.git
> > > > > HEAD
> > > > > > git.mycompany.com[0: 10.66.4.168]:
> > > > errno=Connection
> > > > > refused
> > > > > > fatal: unable to connect a socket
> > (Connection
> > > > refused)
> > > > >
> > > > > It's possible, and likely simpler,
> to
> > use
> > > > git-daemon
> > > > > directly, instead of
> > > > > having it be managed by inetd;
> especially
> > for initial
> > > > > debugging, I'd recommend
> > > > > getting that working before trying to
> > determine if
> > > > > you're having issues with
> > > > > inetd configuration: to do so, just run
> > git-daemon
> > > > with all
> > > > > the same arguments
> > > > > except for --inetd.
> > > > >
> > > > > You said you deleted the xinetd config,
> but
> > that's
> > > > only
> > > > > relevant if your
> > > > > machine actually uses inetd as its
> > super-server. You
> > > > > should do 'ps -A | grep
> > > > > inetd' (which will match either
> inetd or
> > xinetd),
> > > > and
> > > > > see which one is running.
> > > > > If it's inetd, you should be all
> set,
> > and the
> > > > issue
> > > > > doesn't look like inetd
> > > > > (assuming you sent it a signal to
> reload its
> > config
> > > > file).
> > > > > If on the other
> > > > > hand xinetd is running, you need to use
> the
> > xinetd
> > > > config
> > > > > file, and fix the
> > > > > server_args to look like the arguments
> which
> > exist in
> > > > the
> > > > > inetd file. Again,
> > > > > you need to signal xinetd at this point
> to
> > reload its
> > > > > configuration.
> > > > >
> > > > > Based on the linux kernel version
> you're
> > > > reporting,
> > > > > I'm guessing you have some
> > > > > sort of Red Hat based system, which
> uses
> > xinetd to the
> > > > best
> > > > > of my knowledge.
> > > > >
> > > > > > Another question, I got no output
> of
> > > > "netstat |
> > > > > grep 9418". It means no program
> runs at
> > port 9418
> > > > at
> > > > > the public repository machine. Is it
> > correct?
> > > > > >
> > > > > > netstat | grep 9418
> > > > >
> > > > > netstat translates IP addresses to dns
> > names, and
> > > > ports to
> > > > > service names by
> > > > > default; so, given the line listed in
> > /etc/services,
> > > > this
> > > > > will show
> > > > > '0.0.0.0:git' or something.
> Also,
> > it lists
> > > > > established connections, not
> > > > > listening sockets, by default. I'd
> > recommend
> > > > spending
> > > > > some time with the man
> > > > > page if you're going to use it to
> debug
> > your
> > > > setup.
> > > > >
> > > > > Deskin Miller
> > > >
> > > >
> > > >
> > > > --
> > > > 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
> > >
> > >
> > >
> > > --
> > > 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
> >
> > --
> > 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: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-21 0:12 UTC (permalink / raw)
To: J.H.; +Cc: Deskin Miller, git
In-Reply-To: <1227225590.2709.10.camel@localhost.localdomain>
I am not system admin. How to restart it? Can I do this?
sudo xinetd -stayalive -pidfile /var/run/xinetd.pid
Below is the output of current running xinetd
ps -efww | grep xinetd
root 8874 1 0 Sep24 ? 00:00:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
Thanks.
--- On Thu, 11/20/08, J.H. <warthog19@eaglescrag.net> wrote:
> From: J.H. <warthog19@eaglescrag.net>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: garyyang6@yahoo.com
> Cc: "Deskin Miller" <deskinm@umich.edu>, git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:59 PM
> Yes.
>
> - John 'Warthog9' Hawley
> Chief Kernel.org Administrator
>
>
> On Thu, 2008-11-20 at 15:54 -0800, Gary Yang wrote:
> > Do I need to restart xinetd after I made changes in
> /etc/xinetd.d/git-daemon?
> >
> >
> > --- On Thu, 11/20/08, Gary Yang
> <garyyang6@yahoo.com> wrote:
> >
> > > From: Gary Yang <garyyang6@yahoo.com>
> > > Subject: Re: Challenge of setting up git server
> (repository). Please help!
> > > To: "Deskin Miller"
> <deskinm@umich.edu>
> > > Cc: git@vger.kernel.org
> > > Date: Thursday, November 20, 2008, 3:48 PM
> > > I ran the command,"sudo
> > > /usr/local/libexec/git-core/git-daemon git-daemon
> > > --export-all /pub/git &" at public
> repository
> > > machine.
> > >
> > > At my private machine, I ran, git pull
> > > git://svdcgit01.amcc.com/pub/git/u-boot.git
> HEAD"
> > >
> > > I got: "fatal: The remote end hung up
> > > unexpectedly"
> > >
> > > At the public repository server, I got
> > > "'/pub/git/u-boot.git': repository
> not
> > > exported." Any idea of this error?
> > >
> > >
> > > ps -A | grep inetd
> > > 8874 ? 00:00:00 xinetd
> > >
> > > It means it uses xinetd.
> > >
> > > I copied git-daemon back to /etc/xinetd.d and
> added
> > > git-daemon to the server_args. See below:
> > >
> > > cat /etc/xinetd.d/git-daemon
> > > # default: off
> > > # description: The git server offers access to
> git
> > > repositories
> > > service git
> > > {
> > > disable = no
> > > type = UNLISTED
> > > port = 9418
> > > socket_type = stream
> > > wait = no
> > > user = nobody
> > > server =
> > > /usr/local/libexec/git-core/git-daemon
> > > server_args = git-daemon --inetd
> --export-all
> > > --base-path=/pub/git
> > > log_on_failure += USERID
> > > }
> > >
> > >
> > > I kill the daemon
> > > "/usr/local/libexec/git-core/git-daemon
> git-daemon
> > > --export-all /pub/git &".
> > >
> > > Back to my private box, and did git pull. I got
> Connection
> > > refused again. what I did wrong?
> > >
> > > git pull
> git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
> > > svdcgit01.amcc.com[0: 10.66.4.168]:
> errno=Connection
> > > refused
> > > fatal: unable to connect a socket (Connection
> refused)
> > >
> > >
> > >
> > >
> > > --- On Thu, 11/20/08, Deskin Miller
> > > <deskinm@umich.edu> wrote:
> > >
> > > > From: Deskin Miller
> <deskinm@umich.edu>
> > > > Subject: Re: Challenge of setting up git
> server
> > > (repository). Please help!
> > > > To: "Gary Yang"
> <garyyang6@yahoo.com>
> > > > Cc: git@vger.kernel.org
> > > > Date: Thursday, November 20, 2008, 3:08 PM
> > > > On Thu, Nov 20, 2008 at 02:43:30PM -0800,
> Gary Yang
> > > wrote:
> > > > > Many thanks for your explanation. I
> hope I
> > > understand
> > > > what you said. I deleted
> /etc/xinetd.d/git-daemon.
> > > Then, I
> > > > tried to git pull. But, I got connection
> refused. git
> > > uses
> > > > port 9418. Should I request IT Admin to open
> the port
> > > 9418
> > > > for me?
> > > >
> > > > You'll need port 9418 open, yes; but
> since
> > > it's an
> > > > unprivileged port (1024 or
> > > > higher), you can use it as a regular user
> and
> > > don't
> > > > need IT intervention unless you have some
> firewall set
> > > up
> > > > which they need to override for you.
> > > >
> > > > > git pull
> > > git://git.mycompany.com/pub/git/u-boot.git
> > > > HEAD
> > > > > git.mycompany.com[0: 10.66.4.168]:
> > > errno=Connection
> > > > refused
> > > > > fatal: unable to connect a socket
> (Connection
> > > refused)
> > > >
> > > > It's possible, and likely simpler, to
> use
> > > git-daemon
> > > > directly, instead of
> > > > having it be managed by inetd; especially
> for initial
> > > > debugging, I'd recommend
> > > > getting that working before trying to
> determine if
> > > > you're having issues with
> > > > inetd configuration: to do so, just run
> git-daemon
> > > with all
> > > > the same arguments
> > > > except for --inetd.
> > > >
> > > > You said you deleted the xinetd config, but
> that's
> > > only
> > > > relevant if your
> > > > machine actually uses inetd as its
> super-server. You
> > > > should do 'ps -A | grep
> > > > inetd' (which will match either inetd or
> xinetd),
> > > and
> > > > see which one is running.
> > > > If it's inetd, you should be all set,
> and the
> > > issue
> > > > doesn't look like inetd
> > > > (assuming you sent it a signal to reload its
> config
> > > file).
> > > > If on the other
> > > > hand xinetd is running, you need to use the
> xinetd
> > > config
> > > > file, and fix the
> > > > server_args to look like the arguments which
> exist in
> > > the
> > > > inetd file. Again,
> > > > you need to signal xinetd at this point to
> reload its
> > > > configuration.
> > > >
> > > > Based on the linux kernel version you're
> > > reporting,
> > > > I'm guessing you have some
> > > > sort of Red Hat based system, which uses
> xinetd to the
> > > best
> > > > of my knowledge.
> > > >
> > > > > Another question, I got no output of
> > > "netstat |
> > > > grep 9418". It means no program runs at
> port 9418
> > > at
> > > > the public repository machine. Is it
> correct?
> > > > >
> > > > > netstat | grep 9418
> > > >
> > > > netstat translates IP addresses to dns
> names, and
> > > ports to
> > > > service names by
> > > > default; so, given the line listed in
> /etc/services,
> > > this
> > > > will show
> > > > '0.0.0.0:git' or something. Also,
> it lists
> > > > established connections, not
> > > > listening sockets, by default. I'd
> recommend
> > > spending
> > > > some time with the man
> > > > page if you're going to use it to debug
> your
> > > setup.
> > > >
> > > > Deskin Miller
> > >
> > >
> > >
> > > --
> > > 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
> >
> >
> >
> > --
> > 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
>
> --
> 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: Challenge of setting up git server (repository). Please help!
From: J.H. @ 2008-11-20 23:59 UTC (permalink / raw)
To: garyyang6; +Cc: Deskin Miller, git
In-Reply-To: <636576.92732.qm@web37905.mail.mud.yahoo.com>
Yes.
- John 'Warthog9' Hawley
Chief Kernel.org Administrator
On Thu, 2008-11-20 at 15:54 -0800, Gary Yang wrote:
> Do I need to restart xinetd after I made changes in /etc/xinetd.d/git-daemon?
>
>
> --- On Thu, 11/20/08, Gary Yang <garyyang6@yahoo.com> wrote:
>
> > From: Gary Yang <garyyang6@yahoo.com>
> > Subject: Re: Challenge of setting up git server (repository). Please help!
> > To: "Deskin Miller" <deskinm@umich.edu>
> > Cc: git@vger.kernel.org
> > Date: Thursday, November 20, 2008, 3:48 PM
> > I ran the command,"sudo
> > /usr/local/libexec/git-core/git-daemon git-daemon
> > --export-all /pub/git &" at public repository
> > machine.
> >
> > At my private machine, I ran, git pull
> > git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD"
> >
> > I got: "fatal: The remote end hung up
> > unexpectedly"
> >
> > At the public repository server, I got
> > "'/pub/git/u-boot.git': repository not
> > exported." Any idea of this error?
> >
> >
> > ps -A | grep inetd
> > 8874 ? 00:00:00 xinetd
> >
> > It means it uses xinetd.
> >
> > I copied git-daemon back to /etc/xinetd.d and added
> > git-daemon to the server_args. See below:
> >
> > cat /etc/xinetd.d/git-daemon
> > # default: off
> > # description: The git server offers access to git
> > repositories
> > service git
> > {
> > disable = no
> > type = UNLISTED
> > port = 9418
> > socket_type = stream
> > wait = no
> > user = nobody
> > server =
> > /usr/local/libexec/git-core/git-daemon
> > server_args = git-daemon --inetd --export-all
> > --base-path=/pub/git
> > log_on_failure += USERID
> > }
> >
> >
> > I kill the daemon
> > "/usr/local/libexec/git-core/git-daemon git-daemon
> > --export-all /pub/git &".
> >
> > Back to my private box, and did git pull. I got Connection
> > refused again. what I did wrong?
> >
> > git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
> > svdcgit01.amcc.com[0: 10.66.4.168]: errno=Connection
> > refused
> > fatal: unable to connect a socket (Connection refused)
> >
> >
> >
> >
> > --- On Thu, 11/20/08, Deskin Miller
> > <deskinm@umich.edu> wrote:
> >
> > > From: Deskin Miller <deskinm@umich.edu>
> > > Subject: Re: Challenge of setting up git server
> > (repository). Please help!
> > > To: "Gary Yang" <garyyang6@yahoo.com>
> > > Cc: git@vger.kernel.org
> > > Date: Thursday, November 20, 2008, 3:08 PM
> > > On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang
> > wrote:
> > > > Many thanks for your explanation. I hope I
> > understand
> > > what you said. I deleted /etc/xinetd.d/git-daemon.
> > Then, I
> > > tried to git pull. But, I got connection refused. git
> > uses
> > > port 9418. Should I request IT Admin to open the port
> > 9418
> > > for me?
> > >
> > > You'll need port 9418 open, yes; but since
> > it's an
> > > unprivileged port (1024 or
> > > higher), you can use it as a regular user and
> > don't
> > > need IT intervention unless you have some firewall set
> > up
> > > which they need to override for you.
> > >
> > > > git pull
> > git://git.mycompany.com/pub/git/u-boot.git
> > > HEAD
> > > > git.mycompany.com[0: 10.66.4.168]:
> > errno=Connection
> > > refused
> > > > fatal: unable to connect a socket (Connection
> > refused)
> > >
> > > It's possible, and likely simpler, to use
> > git-daemon
> > > directly, instead of
> > > having it be managed by inetd; especially for initial
> > > debugging, I'd recommend
> > > getting that working before trying to determine if
> > > you're having issues with
> > > inetd configuration: to do so, just run git-daemon
> > with all
> > > the same arguments
> > > except for --inetd.
> > >
> > > You said you deleted the xinetd config, but that's
> > only
> > > relevant if your
> > > machine actually uses inetd as its super-server. You
> > > should do 'ps -A | grep
> > > inetd' (which will match either inetd or xinetd),
> > and
> > > see which one is running.
> > > If it's inetd, you should be all set, and the
> > issue
> > > doesn't look like inetd
> > > (assuming you sent it a signal to reload its config
> > file).
> > > If on the other
> > > hand xinetd is running, you need to use the xinetd
> > config
> > > file, and fix the
> > > server_args to look like the arguments which exist in
> > the
> > > inetd file. Again,
> > > you need to signal xinetd at this point to reload its
> > > configuration.
> > >
> > > Based on the linux kernel version you're
> > reporting,
> > > I'm guessing you have some
> > > sort of Red Hat based system, which uses xinetd to the
> > best
> > > of my knowledge.
> > >
> > > > Another question, I got no output of
> > "netstat |
> > > grep 9418". It means no program runs at port 9418
> > at
> > > the public repository machine. Is it correct?
> > > >
> > > > netstat | grep 9418
> > >
> > > netstat translates IP addresses to dns names, and
> > ports to
> > > service names by
> > > default; so, given the line listed in /etc/services,
> > this
> > > will show
> > > '0.0.0.0:git' or something. Also, it lists
> > > established connections, not
> > > listening sockets, by default. I'd recommend
> > spending
> > > some time with the man
> > > page if you're going to use it to debug your
> > setup.
> > >
> > > Deskin Miller
> >
> >
> >
> > --
> > 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
>
>
>
> --
> 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: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 23:54 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <692201.86102.qm@web37905.mail.mud.yahoo.com>
Do I need to restart xinetd after I made changes in /etc/xinetd.d/git-daemon?
--- On Thu, 11/20/08, Gary Yang <garyyang6@yahoo.com> wrote:
> From: Gary Yang <garyyang6@yahoo.com>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "Deskin Miller" <deskinm@umich.edu>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:48 PM
> I ran the command,"sudo
> /usr/local/libexec/git-core/git-daemon git-daemon
> --export-all /pub/git &" at public repository
> machine.
>
> At my private machine, I ran, git pull
> git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD"
>
> I got: "fatal: The remote end hung up
> unexpectedly"
>
> At the public repository server, I got
> "'/pub/git/u-boot.git': repository not
> exported." Any idea of this error?
>
>
> ps -A | grep inetd
> 8874 ? 00:00:00 xinetd
>
> It means it uses xinetd.
>
> I copied git-daemon back to /etc/xinetd.d and added
> git-daemon to the server_args. See below:
>
> cat /etc/xinetd.d/git-daemon
> # default: off
> # description: The git server offers access to git
> repositories
> service git
> {
> disable = no
> type = UNLISTED
> port = 9418
> socket_type = stream
> wait = no
> user = nobody
> server =
> /usr/local/libexec/git-core/git-daemon
> server_args = git-daemon --inetd --export-all
> --base-path=/pub/git
> log_on_failure += USERID
> }
>
>
> I kill the daemon
> "/usr/local/libexec/git-core/git-daemon git-daemon
> --export-all /pub/git &".
>
> Back to my private box, and did git pull. I got Connection
> refused again. what I did wrong?
>
> git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
> svdcgit01.amcc.com[0: 10.66.4.168]: errno=Connection
> refused
> fatal: unable to connect a socket (Connection refused)
>
>
>
>
> --- On Thu, 11/20/08, Deskin Miller
> <deskinm@umich.edu> wrote:
>
> > From: Deskin Miller <deskinm@umich.edu>
> > Subject: Re: Challenge of setting up git server
> (repository). Please help!
> > To: "Gary Yang" <garyyang6@yahoo.com>
> > Cc: git@vger.kernel.org
> > Date: Thursday, November 20, 2008, 3:08 PM
> > On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang
> wrote:
> > > Many thanks for your explanation. I hope I
> understand
> > what you said. I deleted /etc/xinetd.d/git-daemon.
> Then, I
> > tried to git pull. But, I got connection refused. git
> uses
> > port 9418. Should I request IT Admin to open the port
> 9418
> > for me?
> >
> > You'll need port 9418 open, yes; but since
> it's an
> > unprivileged port (1024 or
> > higher), you can use it as a regular user and
> don't
> > need IT intervention unless you have some firewall set
> up
> > which they need to override for you.
> >
> > > git pull
> git://git.mycompany.com/pub/git/u-boot.git
> > HEAD
> > > git.mycompany.com[0: 10.66.4.168]:
> errno=Connection
> > refused
> > > fatal: unable to connect a socket (Connection
> refused)
> >
> > It's possible, and likely simpler, to use
> git-daemon
> > directly, instead of
> > having it be managed by inetd; especially for initial
> > debugging, I'd recommend
> > getting that working before trying to determine if
> > you're having issues with
> > inetd configuration: to do so, just run git-daemon
> with all
> > the same arguments
> > except for --inetd.
> >
> > You said you deleted the xinetd config, but that's
> only
> > relevant if your
> > machine actually uses inetd as its super-server. You
> > should do 'ps -A | grep
> > inetd' (which will match either inetd or xinetd),
> and
> > see which one is running.
> > If it's inetd, you should be all set, and the
> issue
> > doesn't look like inetd
> > (assuming you sent it a signal to reload its config
> file).
> > If on the other
> > hand xinetd is running, you need to use the xinetd
> config
> > file, and fix the
> > server_args to look like the arguments which exist in
> the
> > inetd file. Again,
> > you need to signal xinetd at this point to reload its
> > configuration.
> >
> > Based on the linux kernel version you're
> reporting,
> > I'm guessing you have some
> > sort of Red Hat based system, which uses xinetd to the
> best
> > of my knowledge.
> >
> > > Another question, I got no output of
> "netstat |
> > grep 9418". It means no program runs at port 9418
> at
> > the public repository machine. Is it correct?
> > >
> > > netstat | grep 9418
> >
> > netstat translates IP addresses to dns names, and
> ports to
> > service names by
> > default; so, given the line listed in /etc/services,
> this
> > will show
> > '0.0.0.0:git' or something. Also, it lists
> > established connections, not
> > listening sockets, by default. I'd recommend
> spending
> > some time with the man
> > page if you're going to use it to debug your
> setup.
> >
> > Deskin Miller
>
>
>
> --
> 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: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 23:48 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081120230859.GA13683@euler>
I ran the command,"sudo /usr/local/libexec/git-core/git-daemon git-daemon --export-all /pub/git &" at public repository machine.
At my private machine, I ran, git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD"
I got: "fatal: The remote end hung up unexpectedly"
At the public repository server, I got "'/pub/git/u-boot.git': repository not exported." Any idea of this error?
ps -A | grep inetd
8874 ? 00:00:00 xinetd
It means it uses xinetd.
I copied git-daemon back to /etc/xinetd.d and added git-daemon to the server_args. See below:
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = git-daemon --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I kill the daemon "/usr/local/libexec/git-core/git-daemon git-daemon --export-all /pub/git &".
Back to my private box, and did git pull. I got Connection refused again. what I did wrong?
git pull git://svdcgit01.amcc.com/pub/git/u-boot.git HEAD
svdcgit01.amcc.com[0: 10.66.4.168]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
--- On Thu, 11/20/08, Deskin Miller <deskinm@umich.edu> wrote:
> From: Deskin Miller <deskinm@umich.edu>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:08 PM
> On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang wrote:
> > Many thanks for your explanation. I hope I understand
> what you said. I deleted /etc/xinetd.d/git-daemon. Then, I
> tried to git pull. But, I got connection refused. git uses
> port 9418. Should I request IT Admin to open the port 9418
> for me?
>
> You'll need port 9418 open, yes; but since it's an
> unprivileged port (1024 or
> higher), you can use it as a regular user and don't
> need IT intervention unless you have some firewall set up
> which they need to override for you.
>
> > git pull git://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > git.mycompany.com[0: 10.66.4.168]: errno=Connection
> refused
> > fatal: unable to connect a socket (Connection refused)
>
> It's possible, and likely simpler, to use git-daemon
> directly, instead of
> having it be managed by inetd; especially for initial
> debugging, I'd recommend
> getting that working before trying to determine if
> you're having issues with
> inetd configuration: to do so, just run git-daemon with all
> the same arguments
> except for --inetd.
>
> You said you deleted the xinetd config, but that's only
> relevant if your
> machine actually uses inetd as its super-server. You
> should do 'ps -A | grep
> inetd' (which will match either inetd or xinetd), and
> see which one is running.
> If it's inetd, you should be all set, and the issue
> doesn't look like inetd
> (assuming you sent it a signal to reload its config file).
> If on the other
> hand xinetd is running, you need to use the xinetd config
> file, and fix the
> server_args to look like the arguments which exist in the
> inetd file. Again,
> you need to signal xinetd at this point to reload its
> configuration.
>
> Based on the linux kernel version you're reporting,
> I'm guessing you have some
> sort of Red Hat based system, which uses xinetd to the best
> of my knowledge.
>
> > Another question, I got no output of "netstat |
> grep 9418". It means no program runs at port 9418 at
> the public repository machine. Is it correct?
> >
> > netstat | grep 9418
>
> netstat translates IP addresses to dns names, and ports to
> service names by
> default; so, given the line listed in /etc/services, this
> will show
> '0.0.0.0:git' or something. Also, it lists
> established connections, not
> listening sockets, by default. I'd recommend spending
> some time with the man
> page if you're going to use it to debug your setup.
>
> Deskin Miller
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Deskin Miller @ 2008-11-20 23:08 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <146002.93100.qm@web37908.mail.mud.yahoo.com>
On Thu, Nov 20, 2008 at 02:43:30PM -0800, Gary Yang wrote:
> Many thanks for your explanation. I hope I understand what you said. I deleted /etc/xinetd.d/git-daemon. Then, I tried to git pull. But, I got connection refused. git uses port 9418. Should I request IT Admin to open the port 9418 for me?
You'll need port 9418 open, yes; but since it's an unprivileged port (1024 or
higher), you can use it as a regular user and don't need IT intervention unless you have some firewall set up which they need to override for you.
> git pull git://git.mycompany.com/pub/git/u-boot.git HEAD
> git.mycompany.com[0: 10.66.4.168]: errno=Connection refused
> fatal: unable to connect a socket (Connection refused)
It's possible, and likely simpler, to use git-daemon directly, instead of
having it be managed by inetd; especially for initial debugging, I'd recommend
getting that working before trying to determine if you're having issues with
inetd configuration: to do so, just run git-daemon with all the same arguments
except for --inetd.
You said you deleted the xinetd config, but that's only relevant if your
machine actually uses inetd as its super-server. You should do 'ps -A | grep
inetd' (which will match either inetd or xinetd), and see which one is running.
If it's inetd, you should be all set, and the issue doesn't look like inetd
(assuming you sent it a signal to reload its config file). If on the other
hand xinetd is running, you need to use the xinetd config file, and fix the
server_args to look like the arguments which exist in the inetd file. Again,
you need to signal xinetd at this point to reload its configuration.
Based on the linux kernel version you're reporting, I'm guessing you have some
sort of Red Hat based system, which uses xinetd to the best of my knowledge.
> Another question, I got no output of "netstat | grep 9418". It means no program runs at port 9418 at the public repository machine. Is it correct?
>
> netstat | grep 9418
netstat translates IP addresses to dns names, and ports to service names by
default; so, given the line listed in /etc/services, this will show
'0.0.0.0:git' or something. Also, it lists established connections, not
listening sockets, by default. I'd recommend spending some time with the man
page if you're going to use it to debug your setup.
Deskin Miller
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 22:43 UTC (permalink / raw)
To: Deskin Miller; +Cc: git
In-Reply-To: <20081120221321.GA6349@euler>
Deskin,
Many thanks for your explanation. I hope I understand what you said. I deleted /etc/xinetd.d/git-daemon. Then, I tried to git pull. But, I got connection refused. git uses port 9418. Should I request IT Admin to open the port 9418 for me?
git pull git://git.mycompany.com/pub/git/u-boot.git HEAD
git.mycompany.com[0: 10.66.4.168]: errno=Connection refused
fatal: unable to connect a socket (Connection refused)
Another question, I got no output of "netstat | grep 9418". It means no program runs at port 9418 at the public repository machine. Is it correct?
netstat | grep 9418
--- On Thu, 11/20/08, Deskin Miller <deskinm@umich.edu> wrote:
> From: Deskin Miller <deskinm@umich.edu>
> Subject: Re: Challenge of setting up git server (repository). Please help!
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 2:13 PM
> On Thu, Nov 20, 2008 at 01:39:12PM -0800, Gary Yang wrote:
> >
> > I am working on setting up a git server so that people
> can clone, pull and push their code at
> git.mycompany.com/pub/git+project path.
> > However, I am having challenges. For people who setup
> their git servers, please share your experneces with me and
> tell me what I did wrong.
> > I greatly appreciate it.
> >
> > After I made configurations, I ran the command, git
> update-server-info at the public repository machine. But, I
> got the error.
> >
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > The file /pub/git/u-boot.git/info/refs dose exist.
> >
> > cat /pub/git/u-boot.git/info/refs
> > 87ee4576c4c31b7046fe2bbbdf309eaba5c3f346
> refs/heads/master
> >
> > My question:
> >
> > Is the contet of /pub/git/u-boot.git/hooks/post-update
> correct? Should I change "exec
> git-update-server-info" to "exec git
> update-server-info"?
> >
> > cat /pub/git/u-boot.git/hooks/post-update
> > #!/bin/sh
> > #
> > # An example hook script to prepare a packed
> repository for use over
> > # dumb transports.
> > #
> > # To enable this hook, rename this file to
> "post-update".
> > exec git-update-server-info
> >
> > I tried and changed "exec
> git-update-server-info" to "exec git
> update-server-info" in
> /pub/git/u-boot.git/hooks/post-update. But, I still got same
> error.
> > git pull http://git.mycompany.com/pub/git/u-boot.git
> HEAD
> > fatal:
> http://git.mycompany.com/pub/git/u-boot.git/info/refs not
> found: did you run git update-server-info on the server?
> >
> > Which one is correct? "exec
> git-update-server-info" or "exec git
> update-server-info"? Eventhogh none of them working.
> >
> > Below are my settings:
> >
> > grep 9418 /etc/services
> > git 9418/tcp # Git
> Version Control System
> >
> >
> > grep git /etc/inetd.conf
> > git stream tcp nowait nobody
> /usr/local/libexec/git-core/git-daemon git-daemon --inetd
> --export-all /pub/git
> >
> >
> > cat /etc/xinetd.d/git-daemon
> > # default: off
> > # description: The git server offers access to git
> repositories
> > service git
> > {
> > disable = no
> > type = UNLISTED
> > port = 9418
> > socket_type = stream
> > wait = no
> > user = nobody
> > server =
> /usr/local/libexec/git-core/git-daemon
> > server_args = --inetd --export-all
> --base-path=/pub/git
> > log_on_failure += USERID
> > }
> >
> >
> > I am running git at Linux box:
> > uname -a
> > Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7
> 13:56:44 EST 2007 x86_64 GNU/Linux
> >
> > Are there anything wrong? Please let me know.
>
> You tried to fetch from a http url, but your settings make
> no mention of
> running a web server. git-update-server-info is only
> relevant in the context
> of using a web server to serve git repositories via the
> same http protocol as
> is used by web servers everywhere. git-daemon, on the
> other hand, which is
> what you show configured here, is used to serve git
> repositories via a git://
> url. Its configuration has no effect on whether using http
> to fetch a git
> repository will work or not.
>
> Either use a git:// url to fetch the project, or set up a
> web server which
> serves stuff under /pub/git.
>
> I'll also mention that you appear to have configuration
> for both inetd and
> xinetd, which are two generally mutually-exclusive
> 'super-servers'; and
> furthermore, your configurations are inconsistent in the
> arguments they pass to
> git-daemon: it looks like, were you to replace http:// with
> git://, the inetd
> config would work as listed, while xinetd would not.
>
> Hope that helps,
> Deskin Miller
>
> --
> 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: Challenge of setting up git server (repository). Please help!
From: Asheesh Laroia @ 2008-11-20 22:04 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <829533.97868.qm@web37906.mail.mud.yahoo.com>
On Thu, 20 Nov 2008, Gary Yang wrote:
> I am working on setting up a git server so that people can clone, pull
> and push their code at git.mycompany.com/pub/git+project path. However,
> I am having challenges. For people who setup their git servers, please
> share your experneces with me and tell me what I did wrong. I greatly
> appreciate it.
Have you tried just using gitosis? It's very nice.
http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
is what I read to get started.
Keep in mind you can't clone a git repository with no commits.
-- Asheesh.
--
You look tired.
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Junio C Hamano @ 2008-11-20 22:16 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git, Shawn O. Pearce
In-Reply-To: <fcaeb9bf0811200726x1f2956c6k6f2ca16543a0fbc@mail.gmail.com>
"Nguyen Thai Ngoc Duy" <pclouds@gmail.com> writes:
>> Yes, I also dislike the subtlety, but my "obvious" idea was something
>> like:
>>
>> for i in 1 2 sub/1 sub/2; do
>> touch $i
>> done
>>
>> which just seemed clunky. But:
>>
>>
>> > - touch 1 2 sub/1 sub/2 &&
>> > + touch ./1 ./2 sub/1 sub/2 &&
>>
>>
>> this is less clunky, and I have confirmed that it solves the problem. I
>> just wasn't clever enough to think of it in the first place. ;)
>
> Thanks for catching. The last half also has the same problem. Another
> way is maybe just stay away for those numbers, naming the files by
> ... Just wonder if we could have some ways to automatically
> catch this kind of bug in the future.
A tool to do so essentially amounts to coming up with a set of POSIX
command line tools that know and flag all the known bugs broken platform
tools have, at the same time producing a reasonable end result so that it
can continue running and detecting more portability issues in the scripts.
Using dash as the shell helps to catch use of constructs outside POSIX,
running various GNU tools with POSIXLY_CORRECT=YesPlease may have similar
effects, but quirks specific to particular platforms like the above is
fundamentally hard to check. Running autobuilder farms like Jeff does is
probably the best thing we can do.
^ permalink raw reply
* Re: Challenge of setting up git server (repository). Please help!
From: Deskin Miller @ 2008-11-20 22:13 UTC (permalink / raw)
To: Gary Yang; +Cc: git
In-Reply-To: <829533.97868.qm@web37906.mail.mud.yahoo.com>
On Thu, Nov 20, 2008 at 01:39:12PM -0800, Gary Yang wrote:
>
> I am working on setting up a git server so that people can clone, pull and push their code at git.mycompany.com/pub/git+project path.
> However, I am having challenges. For people who setup their git servers, please share your experneces with me and tell me what I did wrong.
> I greatly appreciate it.
>
> After I made configurations, I ran the command, git update-server-info at the public repository machine. But, I got the error.
>
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> The file /pub/git/u-boot.git/info/refs dose exist.
>
> cat /pub/git/u-boot.git/info/refs
> 87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
>
> My question:
>
> Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
>
> cat /pub/git/u-boot.git/hooks/post-update
> #!/bin/sh
> #
> # An example hook script to prepare a packed repository for use over
> # dumb transports.
> #
> # To enable this hook, rename this file to "post-update".
> exec git-update-server-info
>
> I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
> git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
> fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
>
> Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
>
> Below are my settings:
>
> grep 9418 /etc/services
> git 9418/tcp # Git Version Control System
>
>
> grep git /etc/inetd.conf
> git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
>
>
> cat /etc/xinetd.d/git-daemon
> # default: off
> # description: The git server offers access to git repositories
> service git
> {
> disable = no
> type = UNLISTED
> port = 9418
> socket_type = stream
> wait = no
> user = nobody
> server = /usr/local/libexec/git-core/git-daemon
> server_args = --inetd --export-all --base-path=/pub/git
> log_on_failure += USERID
> }
>
>
> I am running git at Linux box:
> uname -a
> Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
>
> Are there anything wrong? Please let me know.
You tried to fetch from a http url, but your settings make no mention of
running a web server. git-update-server-info is only relevant in the context
of using a web server to serve git repositories via the same http protocol as
is used by web servers everywhere. git-daemon, on the other hand, which is
what you show configured here, is used to serve git repositories via a git://
url. Its configuration has no effect on whether using http to fetch a git
repository will work or not.
Either use a git:// url to fetch the project, or set up a web server which
serves stuff under /pub/git.
I'll also mention that you appear to have configuration for both inetd and
xinetd, which are two generally mutually-exclusive 'super-servers'; and
furthermore, your configurations are inconsistent in the arguments they pass to
git-daemon: it looks like, were you to replace http:// with git://, the inetd
config would work as listed, while xinetd would not.
Hope that helps,
Deskin Miller
^ permalink raw reply
* Challenge of setting up git server (repository). Please help!
From: Gary Yang @ 2008-11-20 21:39 UTC (permalink / raw)
To: git
I am working on setting up a git server so that people can clone, pull and push their code at git.mycompany.com/pub/git+project path.
However, I am having challenges. For people who setup their git servers, please share your experneces with me and tell me what I did wrong.
I greatly appreciate it.
After I made configurations, I ran the command, git update-server-info at the public repository machine. But, I got the error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
The file /pub/git/u-boot.git/info/refs dose exist.
cat /pub/git/u-boot.git/info/refs
87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
My question:
Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
cat /pub/git/u-boot.git/hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
Below are my settings:
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
grep git /etc/inetd.conf
git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I am running git at Linux box:
uname -a
Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
Are there anything wrong? Please let me know.
^ permalink raw reply
* Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Gary Yang @ 2008-11-20 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811201204300.30769@pacific.mpi-cbg.de>
I ran the command, git update-server-info at the public repository machine. But, I still got the same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
The file /pub/git/u-boot.git/info/refs do exist.
cat /pub/git/u-boot.git/info/refs
87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
My question:
Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
cat /pub/git/u-boot.git/hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
Below are my settings:
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
grep git /etc/inetd.conf
git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I am running git at Linux box:
uname -a
Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
Are there anything wrong? Please let me know.
--- On Thu, 11/20/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:05 AM
> Hi,
>
> On Wed, 19 Nov 2008, Gary Yang wrote:
>
> > I did not run post-update at public repository
> manually. Do I need to
> > run it for the very first time?
>
> You need to run it when you installed the hook _after_
> seeing the message
> "did you run...".
>
> Ciao,
> Dscho
> --
> 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: [PATCH v2] Updated Swedish translation (514t0f0u).
From: Shawn O. Pearce @ 2008-11-20 19:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Peter Krefting, Git Mailing List, Mikael Magnusson
In-Reply-To: <49257790.5010105@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Peter Krefting wrote:
>>
>>>> +msgid "Blame History Context Radius (days)"
>>>> +msgstr "Historikkontextradie för klandring (dagar)"
>>> At least a 100 points in scrabble for "historikkontextradie". How about
>>> "Historikradie för klandring (dagar)"?
>>
>> I struggled with this one. I still haven't got the faintest clue what
>> it is all about, but I have changed it as you suggested...
>
> I *think* it's about how many days to go back when viewing blame output
> for the selected file. Shawn, can you enlighten us here?
Yes, exactly. It tells git-gui what to pass to gitk. When you are in
the blame viewer you can open a "gitk --since=$d.days $commit -- $path"
window and $d is the property this message names.
--
Shawn.
^ permalink raw reply
* Re: git and mtime
From: Joey Hess @ 2008-11-20 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0811201223300.19665@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
On Thu, 20 Nov 2008, Roger Leigh wrote:
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar). I'm committing exactly what's in the tarball with
> no changes (this is a requirement). I can't change the source prior
> to commit.
Note that pristine-tar will work no matter what the mtimes or other file
metadata are, none of that affects generation of deltas or regeneration
of tarballs from them.
Also, the source you commit does not really have to be identical to
what's in the tarball. (Despite what it may say in the man page. ;-)
A larger delta will be generated if something is different.
So, three possible approaches:
1. Run make or whatever you need to do before running pristine-tar,
and put up with a larger delta.
2. Before building, you could use pristine-tar to extract the original
tarball, and then have a program examine that tarball, and reset the
mtimes in your build tree to match the mtimes of files in it.
(Or you could duplicate the info with metastore -m, which could be
restored quicker.)
3. Store uncompressed tarballs in git, so that they will pack
efficiently, and use pristine-gz to regenerate the pristine .tar.gz.
Only mentioned because this could be more space efficient than option
#1, if the pristine-tar deltas get too large.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-20 18:56 UTC (permalink / raw)
To: Git List
This avoids the following misleading error message:
error: unable to create temporary sha1 filename ./objects/15: File exists
mkstemp can fail for many reasons, one of which, ENOENT, can occur if
the directory for the temp file doesn't exist. create_tmpfile tried to
handle this case by always trying to mkdir the directory, even if it
already existed. This caused errno to be clobbered, so one cannot tell
why mkstemp really failed, and it truncated the buffer to just the
directory name, resulting in the strange error message shown above.
Note that in both occasions that I've seen this failure, it has not been
due to a missing directory, or bad permissions, but some other, unknown
mkstemp failure mode that did not occur when I ran git again. This code
could perhaps be made more robust by retrying mkstemp, in case it was a
transient failure.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..927fb64 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen) {
+ if (fd < 0 && dirlen && errno == ENOENT) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
--
1.5.6.5
^ permalink raw reply related
* Re: New converstion tool: svn2git.py
From: Daniel Barkalow @ 2008-11-20 18:49 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
On Wed, 19 Nov 2008, Neil Schemenauer wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
Probably the best thing in git would be to have the parent of the initial
commit on that branch be revision 3 of trunk; it will look like a big
rename of everything from subdir/* into the project root directory, which
is essentially what happened.
> Would git still efficently pack that or would you end up with extra
> blobs?
git will only ever store a single copy of identical file contents,
regardless of anything at all. Furthermore, when making a pack, git
compresses everything in the pack against everything else in the pack. Its
heuristics also ignore the leading directory names in guessing which blobs
are likely to help in compression (because there's a good chance that
anything named "Makefile" anywhere is useful in compressing anything else
named "Makefile").
-Daniel
*This .sig left intentionally blank*
^ 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