* Re: Git.pm
From: Jakub Narebski @ 2008-11-21 2:56 UTC (permalink / raw)
To: Nadim Khemir, Petr Baudis, Lea Wiemann; +Cc: git
In-Reply-To: <200811191856.44252.nadim@khemir.net>
nadim khemir <nadim@khemir.net> writes:
(CC-ed Petr Baudis and Lea Wiemann).
> Hi, I'm new on this mailing list and quite new to git too. I said
> on IRC that I develop mainly in Perl (http://search.cpan.org/~nkh/)
> when I do open source. I heard that Git.pm needed some love and I
> can take over its maintenance if there are things that need to be
> done.
>
> I need to know:
>
> - what needs to be done
> - who was doing maintenanace before
> - how do you want to release it
> (perl modules are best placed on CPAN (too))
> - what (and who) is depending on Git.pm
> - what would be expected of me
>
> As you may have seen in another mail, the Perl community is getting
> interested in git.
Actually there are one and a half of Perl interfaces to Git: Git.pm
created by Pasky (who, as far as I understand is not a Perl hacker)
which is in git.git repository, and Git::Repo and friends created by
Lea Wiemann during her work on "gitweb caching" project at Google
Summer of Code 2008 (you can find her repository at git wiki page
http://git.or.cz/gitwiki/SoC2008Projects).
If I remember history of Git.pm correctly, it was first created as a
way to collect together and uniquify various versions of safe_pipe and
safe_qx which were used by various Perl scripts in git; something like
Perl version of git-sh-setup.sh for shell scripts... At first it even
used XS in parts, but the build system was deemed too unportable (it
depended on -fPIC). One of design decisions was to use Error.pm for
throwing errors; I'm not a Perl hacker, so I cannot say if this was a
good decision, and if implementation of this part is good.
Lea Wiemann work on Git::Repo and friends was created as object
oriented interface. It was build from ground up instead of reusing
Git.pm to be not encumbered by Git.pm cruft... unfortunately it means
also abandoning all the work that went in Git.pm to make it portable
(read: make it work with crippled ActiveState Perl). You can find
discussion on the design of Git::Repo and decision of it being clean
state implementation at link given by Pasky.
P.S. I have "[RFC] Git Perl bindings, and OO interface" half-written
(well, more like a third), a bit stalled. I'll try to find time to
finish it and send it to git mailing list.
P.P.S. "git grep 'use Git'" finds git-add--interactive.perl,
git-send-email and git-svn. Probably other Perl scripts (including
gitweb) could make use of it...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] mmap implementation for mingw.
From: Vasyl Vavrychuk @ 2008-11-21 2:50 UTC (permalink / raw)
To: git
Here is simple and restricted implementation of mmap using CreateFileMapping,
MapViewOfFile.
---
compat/mingw.c | 27 +++++++++++++++++++++++++++
compat/mingw.h | 6 ++++++
git-compat-util.h | 2 ++
3 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index b534a8a..a6a5081 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -994,3 +994,30 @@ void mingw_open_html(const char *unixpath)
printf("Launching default browser to display HTML ...\n");
ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
}
+
+void *mingw_mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset)
+{
+ HANDLE handle;
+
+ if (start != NULL || !(flags & MAP_PRIVATE))
+ die("Invalid usage of mingw_mmap");
+
+ if (offset % getpagesize() != 0)
+ die("Offset does not match the memory allocation granularity");
+
+ handle = CreateFileMapping((HANDLE)_get_osfhandle(fd), NULL,
PAGE_WRITECOPY,
+ 0, 0, NULL);
+
+ if (handle != NULL) {
+ start = MapViewOfFile(handle, FILE_MAP_COPY, 0, offset,
length);
+ CloseHandle(handle);
+ }
+
+ return start;
+}
+
+int mingw_munmap(void *start, size_t length)
+{
+ UnmapViewOfFile(start);
+ return 0;
+}
diff --git a/compat/mingw.h b/compat/mingw.h
index 4f275cb..1b2a098 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -183,6 +183,12 @@ static inline unsigned int git_ntohl(unsigned int x)
sig_handler_t mingw_signal(int sig, sig_handler_t handler);
#define signal mingw_signal
+void *mingw_mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);
+#define mmap mingw_mmap
+
+int mingw_munmap(void *start, size_t length);
+#define munmap mingw_munmap
+
/*
* ANSI emulation wrappers
*/
diff --git a/git-compat-util.h b/git-compat-util.h
index e20b1e8..8f3d070 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -175,10 +175,12 @@ static inline const char *skip_prefix(const char *str,
const char *prefix)
#define MAP_FAILED ((void*)-1)
#endif
+#ifndef __MINGW32__
#define mmap git_mmap
#define munmap git_munmap
extern void *git_mmap(void *start, size_t length, int prot, int flags, int fd,
off_t offset);
extern int git_munmap(void *start, size_t length);
+#endif
/* This value must be multiple of (pagesize * 2) */
#define DEFAULT_PACKED_GIT_WINDOW_SIZE (1 * 1024 * 1024)
--
1.5.6.1.1071.g76fb
^ permalink raw reply related
* '/pub/git/u-boot.git': not in whitelist. Please help!
From: Gary Yang @ 2008-11-21 2:20 UTC (permalink / raw)
To: git
At git public repository server, I started git-daemon
sudo git-daemon git-daemon -verbose --inetd --export-all --base-path=/pub/git &
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
At my private machine:
git pull git://svdcgit01.amcc.com/pub/git/u-boot.git
fatal: The remote end hung up unexpectedly
At the git public repository server, I got:
'/pub/git/u-boot.git': not in whitelist
ls /pub/git/u-boot.git
branches/ config description HEAD hooks/ info/ objects/ refs/
What I did wrong? Please help.
^ permalink raw reply
* Re: git-svn confused by "empty" (svn prop change) commit
From: paulfred @ 2008-11-21 1:30 UTC (permalink / raw)
To: git
In-Reply-To: <m28wrfhz17.fsf@gmail.com>
paulfred <paul.fredrickson@gmail.com> writes:
>
> Other (perhaps important) details: I created the repository several months
> ago,and only recently put "[svn] noMetadata = true" in my config file because
> I'm the only person on the team using git, and nobody else wanted to see the
> git-svn-id messages.
>
Okay, I see that I missed in the documentation where it says setting noMetadata
"must be done *before* any history is imported and these settings should never
be changed once they are set. User error.
>
> I suppose I could nuke everything and clone another shallow copy of the code
> from some point after the bad commit, but I'd be happy with any kind of
> work around that gets me dcommitting again.
>
So, that is what I tried to do today, only it doesn't appear to work either!
Here's what I tried in more detail:
$ git svn init -T http://project.com/svn/trunk project --no-metadata
Then I edited my config to look like this:
[svn-remote "svn"]
noMetadata = 1
url = http://project.com/svn
fetch = trunk/dev:refs/remotes/trunk
only changing the fetch line (I don't want to track web pages, etc. which
are also under trunk). Followed by:
$ git svn fetch --revision 1156
$ git svn fetch
(now it actually pulls everything since 1156 and checks out master)
[hack, hack, hack]
$ git svn rebase
Unable to determine upstream SVN information from working tree history
at which point I realize I am probably screwed. But I try it anyway,
since svn tells me no one else has checked anything in yet:
$ git svn dcommit
Unable to determine upstream SVN information from HEAD history.
Perhaps the repository is empty. at /usr/local/libexec/git-core/git-svn line 435.
So apparently my problem is NOT the empty commit at all, but trying to use
noMetadata. I am surprised that it fails on a fresh download though. Is there
something I might have done while hacking that would cause git-svn to lose
track of trunk again? Is my only option to convince everyone to ignore
the "noise" in my comments?
Thanks,
--Paul
^ permalink raw reply
* 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
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