git-push through git protocol

git-push through git protocol

[Bill Lear]

We have a secure network in which we run all of our git-supported
development activities.  We would like to be able to do git-push
through the git protocol.  Reasons: 1) it seems more efficient; 2) we
have run into problems with developers having different umasks ---
when run through ssh, we ran into file permissions problems and
instead of tracking down each umask issue the developer has (and,
frankly, not wanting to change their default), we resorted to fixing
up the permissions inside of the update hook (chmod -R ug+w, I think);
3) we would prefer a single protocol instead of sometimes pulling with
git and pushing with ssh.

It seems there should be a way to configure a repo or the git daemon
to say "Allow push operations".

I looked through the release notes Junio posted for 1.5.0-rc2, but
found no reference to the git daemon.


Bill

Re: git-push through git protocol

[Jakub Narebski]

[Cc: git@vger.kernel.org]

Bill Lear wrote:

> We have a secure network in which we run all of our git-supported
> development activities.  We would like to be able to do git-push
> through the git protocol.  Reasons: 1) it seems more efficient; 2) we
> have run into problems with developers having different umasks ---
> when run through ssh, we ran into file permissions problems and
> instead of tracking down each umask issue the developer has (and,
> frankly, not wanting to change their default), we resorted to fixing
> up the permissions inside of the update hook (chmod -R ug+w, I think);
> 3) we would prefer a single protocol instead of sometimes pulling with
> git and pushing with ssh.
> 
> It seems there should be a way to configure a repo or the git daemon
> to say "Allow push operations".
> 
> I looked through the release notes Junio posted for 1.5.0-rc2, but
> found no reference to the git daemon.

git:// protocol is not authenticated. git by design allow push only through
authenticated protocols, i.e. local, ssh:// (git+ssh://), http(s):// with
WebDAV, probably in the future ftps://. 

rsync:// (deprecated) and git:// are fetch only (read-only) protocols.
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-push through git protocol

[Linus Torvalds]

On Sun, 21 Jan 2007, Jakub Narebski wrote:
> > 
> > It seems there should be a way to configure a repo or the git daemon
> > to say "Allow push operations".
> > 
> > I looked through the release notes Junio posted for 1.5.0-rc2, but
> > found no reference to the git daemon.
> 
> git:// protocol is not authenticated. git by design allow push only through
> authenticated protocols, i.e. local, ssh:// (git+ssh://), http(s):// with
> WebDAV, probably in the future ftps://. 

Well, it _should_ actually be truly fairly trivial to allow pushing over 
the git:// protocol, and while it's not authenticated, I could well 
imagine that it would make sense from within a firewalled setup (where 
nobody but trusted internal people can reach the git port anyway).

So in that sense, I do think Bill's request makes some amount of sense.

At the same time, I suspect it's not a great idea, unless you also add 
*some* kind of logging facility to git-daemon.

But here is a trivial patch that *MAY* do what Bill wants.

NOTE! "git-receive-pack" is disabled by default, so you need to enable it 
explicitly by starting git-daemon with the "--enable=receive-pack" command  
line argument, or by having your config enable it automatically.

And a second note: I obviously didn't test it. I'm Linus. I don't do no 
steenking testing..

		Linus

---
diff --git a/daemon.c b/daemon.c
index f039534..9590372 100644
--- a/daemon.c
+++ b/daemon.c
@@ -372,9 +372,16 @@ static int upload_archive(void)
 	return -1;
 }
 
+static int receive_pack(void)
+{
+	execl_git_cmd("receive-pack", ".", NULL);
+	return -1;
+}
+
 static struct daemon_service daemon_service[] = {
 	{ "upload-archive", "uploadarch", upload_archive, 0, 1 },
 	{ "upload-pack", "uploadpack", upload_pack, 1, 1 },
+	{ "receive-pack", "receivepack", receive_pack, 0, 1 },
 };
 
 static void enable_service(const char *name, int ena) {

Re: git-push through git protocol

[Bill Lear]

Interesting.  This is exactly (if memory serves) the patch that I
tried myself, but in retrospect, I think I only tried it on the client
side, for some idiotic reason (I'll plead cold weather here in
Austin).  I'll see if I can get this installed and tested.

Thanks Linus.


Bill

On Sunday, January 21, 2007 at 11:04:13 (-0800) Linus Torvalds writes:
>
>
>On Sun, 21 Jan 2007, Jakub Narebski wrote:
>> > 
>> > It seems there should be a way to configure a repo or the git daemon
>> > to say "Allow push operations".
>> > 
>> > I looked through the release notes Junio posted for 1.5.0-rc2, but
>> > found no reference to the git daemon.
>> 
>> git:// protocol is not authenticated. git by design allow push only through
>> authenticated protocols, i.e. local, ssh:// (git+ssh://), http(s):// with
>> WebDAV, probably in the future ftps://. 
>
>Well, it _should_ actually be truly fairly trivial to allow pushing over 
>the git:// protocol, and while it's not authenticated, I could well 
>imagine that it would make sense from within a firewalled setup (where 
>nobody but trusted internal people can reach the git port anyway).
>
>So in that sense, I do think Bill's request makes some amount of sense.
>
>At the same time, I suspect it's not a great idea, unless you also add 
>*some* kind of logging facility to git-daemon.
>
>But here is a trivial patch that *MAY* do what Bill wants.
>
>NOTE! "git-receive-pack" is disabled by default, so you need to enable it 
>explicitly by starting git-daemon with the "--enable=receive-pack" command  
>line argument, or by having your config enable it automatically.
>
>And a second note: I obviously didn't test it. I'm Linus. I don't do no 
>steenking testing..

Re: git-push through git protocol

[Johannes Schindelin]

Hi,

On Sun, 21 Jan 2007, Linus Torvalds wrote:

> NOTE! "git-receive-pack" is disabled by default, so you need to enable 
> it explicitly by starting git-daemon with the "--enable=receive-pack" 
> command line argument, or by having your config enable it automatically.

This is not a great idea. At least a config variable should be responsible 
for that.

> And a second note: I obviously didn't test it. I'm Linus. I don't do no 
> steenking testing..

Why do you mention that? We know...

Ciao,
Dscho

Re: git-push through git protocol

[Bill Lear]

I did the steenking testing and it appears to fail.  This is with
1.4.4.1 (applied the patch by hand to daemon.c, rebuilt and installed
on my local workstation).  I get this (clone worked fine) on my test
repo:

% git push git://localhost/fongo
updating 'refs/heads/master'
  from a54b51ffc155737d8ccebd645f0d2036072d669f
  to   c5599ebdeae970eaa0163374a6c5d8b216fc390a
fatal: read error (Bad file descriptor)
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
fatal: sha1 file '<stdout>' write error (Bad file descriptor)

My /etc/xinet.d/git-daemon looks like this:

service git
{
        disable         = no
        type            = UNLISTED
        port            = 9418
        socket_type     = stream
        wait            = no
        user            = nobody
        server          = /usr/bin/git-daemon
        server_args     = --enable=receive-pack --verbose --syslog --inetd --export-all --base-path=/repos/git
        log_on_failure  += USERID
}

Will try to dig into this more if I can...


Bill

On Sunday, January 21, 2007 at 11:04:13 (-0800) Linus Torvalds writes:
>
>
>On Sun, 21 Jan 2007, Jakub Narebski wrote:
>> > 
>> > It seems there should be a way to configure a repo or the git daemon
>> > to say "Allow push operations".
>> > 
>> > I looked through the release notes Junio posted for 1.5.0-rc2, but
>> > found no reference to the git daemon.
>> 
>> git:// protocol is not authenticated. git by design allow push only through
>> authenticated protocols, i.e. local, ssh:// (git+ssh://), http(s):// with
>> WebDAV, probably in the future ftps://. 
>
>Well, it _should_ actually be truly fairly trivial to allow pushing over 
>the git:// protocol, ...

Re: git-push through git protocol

[Linus Torvalds]

On Sun, 21 Jan 2007, Bill Lear wrote:
>
> I did the steenking testing and it appears to fail.

Ok, I did the test too. It does _appear_ to fail, where the keyword is 
actually the "appear". 

I get

	[torvalds@woody new-repo]$ git push
	updating 'refs/heads/master'
	  from b66385f8f77014d9c3985b1ed1654401508392ad
	  to   2cd693b97b450378fa300ddf6b093aef236953cd
	Generating pack...
	Done counting 4 objects.
	Result has 3 objects.
	Deltifying 3 objects.
	 100% (3/3) done
	Writing 3 objects.
	 100% (3/3) done
	Total 3 (delta 0), reused 0 (delta 0)
	fatal: read error (Bad file descriptor)

On the pushing side, but it all did actually work fine, and trying to push 
again gets you a

	[torvalds@woody new-repo]$ git push
	Everything up-to-date

and the repo I pushed to did get the changes and checks out ok.

So the patch works, but yeah, there's a few issues:

 - the native git:// protocol doesn't open a stream for stderr like ssh 
   does, so all the nice status updates go to the _daemon_ stderr, and on 
   the daemon side I see:

	Unpacking 3 objects
	 100% (3/3) done
	refs/heads/master: b66385f8f77014d9c3985b1ed1654401508392ad -> 2cd693b97b450378fa300ddf6b093aef236953cd

   which might actually be nice from a debugging and logging standpoint, 
   except it doesn't log enough to really be useful.

 - git-send-pack wants expects the status report, and doesn't get one. 
   That, in turn, seems to be because it expects "out" and "in" to be 
   different file descriptors, and with the git:// protocol they aren't 
   (they're the same file descriptor)

This attached patch should fix the second problem. Maybe.

		Linus
---
diff --git a/send-pack.c b/send-pack.c
index cd478dd..3d3ca07 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -327,6 +327,8 @@ static int send_pack(int in, int out, int nr_refspec, char **refspec)
 	}
 
 	packet_flush(out);
+	if (out == in)
+		out = dup(out);
 	if (new_refs)
 		ret = pack_objects(out, remote_refs);
 	close(out);

Re: git-push through git protocol

[Martin Langhoff]

On 1/22/07, Bill Lear <rael@zopyra.com> wrote:
> 2) we have run into problems
> with developers having different umasks ---

This is a non-issue. Just do git-repo-config core.sharedrepository 1
on each repo.

> 3) we would prefer a single protocol instead of sometimes pulling with
> git and pushing with ssh.

Internally we always use ssh+git. No problem.

cheers



m

Re: git-push through git protocol

[Bill Lear]

On Monday, January 22, 2007 at 12:49:02 (+1300) Martin Langhoff writes:
>On 1/22/07, Bill Lear <rael@zopyra.com> wrote:
>> 2) we have run into problems
>> with developers having different umasks ---
>
>This is a non-issue. Just do git-repo-config core.sharedrepository 1
>on each repo.

Does this have the same effect as 'git --bare init-db --shared'?
If so, I thought that was the way we initialized our company repo,
though our config file reads:

[core]
        repositoryformatversion = 0
        filemode = true

I also note that our company repo does not have this:

[receive]
        denyNonFastforwards = true

which now makes me nervous.  I would assume this would be a good thing
to have, no?


Bill

Re: git-push through git protocol

[Linus Torvalds]

On Sun, 21 Jan 2007, Linus Torvalds wrote:
> 
>  - git-send-pack wants expects the status report, and doesn't get one. 
>    That, in turn, seems to be because it expects "out" and "in" to be 
>    different file descriptors, and with the git:// protocol they aren't 
>    (they're the same file descriptor)
> 
> This attached patch should fix the second problem. Maybe.

This actually looks like potentially a generic real problem.

It so *happens* that git_connect() is different from all the other 
connection types in that it returns the same socket for both input and 
output. All the others return separate fd's for the input and output 
sides, because they end up using pipes.

This is not normally a problem, since people just use "read()" and 
"write()" on the things. Who cares if they are the same fd or not? Nobody.

Well, almost nobody. Anybody who ends up closing the file descriptors will 
inevitably care. In this case it was git-send-pack (through send_pack() 
that happened to close the two file descriptors, but because they were 
actually the same one, it would end up (a) closing the same thing twice 
and (b) doing some operations on an already-closed fd).

I really think this should be fixed, regardless of whether we want to have 
git:// usable for pushing or not, because it's really conceptually a bug. 

We could do it either with my stupid patch (which just makes "send_pack()" 
do the dup itself when they happen to be identical, and thus avoids the 
problem in the caller), but it might actually make sense to just make the 
rule be that "git_connect()" always returns separate file descriptors for 
the input/output cases so that nobody can ever be confused, and so that 
you can always close those things independently.

In fact, looking more closely, a lot of the other users of git_connect() 
seem to avoid it by simply leaking file descriptors (ie builtin-archive.c 
closes only one of the file descriptors). Others (like receive-pack.c) 
close both, but make sure that they always close them together, and 
apparently fetch-pack.c just makes sure to close them together (so the 
second close might cause EBADF, but in the absense of any threading or 
signals, you're ok).

Same goes for peek-remote: it also just closes the same fd twice, and 
depends on it having no bad side effects (which is true, modulo race 
conditions that we don't have because we're single-threaded).

But everything considered, I'd almost suggest just solving this by the 
trivial one-liner to make git_connect() _always_ return two separate file 
descriptors, so that nobody needs to do strange tests and so that we don't 
call "close()" on the same file descriptor twice.

So I'd suggest this simple change to "connect.c". Yeah, it adds an 
"unnecessary" (but cheap) system call to the git:// case, but it allows 
all users to stop worrying about whether the result is a single in-out 
file descriptor or two separate file descriptors for the in/out cases.

As shown by the send-pack example, there was actually code out there that 
depended on the "two separate file descriptors" case, which we get for all 
the normal and secure cases anyway (since they use pipe() to create the 
communication channels with a proxy or ssh or whatever).

So Junio, I'd suggest adding this whether you then want to add the trivial 
code to allow pushing over git:// too or not. One less special case to 
worry about.

		Linus

---
diff --git a/connect.c b/connect.c
index 66daa11..7844888 100644
--- a/connect.c
+++ b/connect.c
@@ -529,7 +529,7 @@ static void git_tcp_connect(int fd[2], char *host)
 	int sockfd = git_tcp_connect_sock(host);
 
 	fd[0] = sockfd;
-	fd[1] = sockfd;
+	fd[1] = dup(sockfd);
 }
 
 

Re: git-push through git protocol

[Martin Langhoff]

On 1/22/07, Bill Lear <rael@zopyra.com> wrote:
> On Monday, January 22, 2007 at 12:49:02 (+1300) Martin Langhoff writes:
> >On 1/22/07, Bill Lear <rael@zopyra.com> wrote:
> >> 2) we have run into problems
> >> with developers having different umasks ---
> >
> >This is a non-issue. Just do git-repo-config core.sharedrepository 1
> >on each repo.
>
> Does this have the same effect as 'git --bare init-db --shared'?
> If so, I thought that was the way we initialized our company repo,
> though our config file reads:
>
> [core]
>         repositoryformatversion = 0
>         filemode = true

You should check your repos, ours all have

[core]
        sharedrepository = true

which I manually set doing

  GIT_DIR=xx.git git-repo-config core.sharedrepository true

and the group is set to "git" which all our devs are part of. Works great.

WRT denyNonFastforwards -- even without that, git refuses to push if
it's not a fast-forward. Maybe if I had the branch set to +headname.
In any case, you have to try real hard to muck that up.

cheers


m

Re: git-push through git protocol

[Jakub Narebski]

Martin Langhoff wrote:

> WRT denyNonFastforwards -- even without that, git refuses to push if
> it's not a fast-forward. Maybe if I had the branch set to +headname.
> In any case, you have to try real hard to muck that up.

With denyNonFastforwards even push --force, or push +head wouldn't work.
Without you need the above to push not fast-forward changes (rewind
history).
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: git-push through git protocol

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> So Junio, I'd suggest adding this whether you then want to add the trivial 
> code to allow pushing over git:// too or not. One less special case to 
> worry about.
>
> 		Linus
>
> ---
> diff --git a/connect.c b/connect.c
> index 66daa11..7844888 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -529,7 +529,7 @@ static void git_tcp_connect(int fd[2], char *host)
>  	int sockfd = git_tcp_connect_sock(host);
>  
>  	fd[0] = sockfd;
> -	fd[1] = sockfd;
> +	fd[1] = dup(sockfd);
>  }

Yeah, I think this is very sensible thing to do.

[PATCH] Make sure git_connect() always give two file descriptors.

[Junio C Hamano]

Earlier, git_connect() returned the same fd when the destination
was remote (i.e.  we used socket to communicate with it) and two
separate fds when the destination was local (i.e. we used
pipe(2)).

This forced callers who do close() and dup() to really care
which was which, and most of the existing callers got this
wrong, although without much visible ill effect.

Fix it to uniformly use two separate fd, so if somebody wants to
close only reader side can just do close() on it without
worrying about it accidentally also closing the writer side or
vice versa.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 * Your patch; just checking if the above log message makes sense...

 connect.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/connect.c b/connect.c
index 66daa11..7844888 100644
--- a/connect.c
+++ b/connect.c
@@ -529,7 +529,7 @@ static void git_tcp_connect(int fd[2], char *host)
 	int sockfd = git_tcp_connect_sock(host);
 
 	fd[0] = sockfd;
-	fd[1] = sockfd;
+	fd[1] = dup(sockfd);
 }
 
 
-- 
1.5.0.rc2

Re: git-push through git protocol

[Bill Lear]

On Sunday, January 21, 2007 at 14:00:16 (-0800) Linus Torvalds writes:
>On Sun, 21 Jan 2007, Bill Lear wrote:
>> I did the steenking testing and it appears to fail.
>
>Ok, I did the test too. It does _appear_ to fail, where the keyword is 
>actually the "appear". 

I applied the patches and I get failure.  I have appended the entire
test case after my sig.  The last part reads:

% git push
updating 'refs/heads/master'
  from fee4efae4f3b98cce0fe85efc746291157fffbcd
  to   e1179a3bf842ddcf4643740a396b46ce7ebd4ada
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
unpack unpacker exited with error code
ng refs/heads/master n/a (unpacker error)

This is on a Centos 4.3 system, under bash.  I am pushing to a git
server running on my local host.


Bill

% cat /etc/xinet.d/git-daemon
service git
{
        disable         = no
        type            = UNLISTED
        port            = 9418
        socket_type     = stream
        wait            = no
        user            = nobody
        server          = /opt/git-1.5.0-rc2/bin/git-daemon
        server_args     = --enable=receive-pack --verbose --syslog --inetd --export-all --base-path=/repos/git
        log_on_failure  += USERID
}
% mkdir /repos/git/foo
% cd /repos/git/foo
% git --bare init-db --shared
Initialized empty shared Git repository in /home/repos/git/foo/
% mkdir ~/foo
% cd ~/foo
% git init-db
% echo foo > foo
% git add foo
% git commit -a -m foo
% git push /repos/git/foo master
updating 'refs/heads/master'
  from 0000000000000000000000000000000000000000
  to   fee4efae4f3b98cce0fe85efc746291157fffbcd
Generating pack...
Done counting 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
Unpacking 3 objects
 100% (3/3) done
refs/heads/master: 0000000000000000000000000000000000000000 -> fee4efae4f3b98cce0fe85efc746291157fffbcd
% cd ~/
% rm -rf foo
% git clone git://localhost/foo
Initialized empty Git repository in /home/blear/foo/.git/
remote: Generating pack...
remote: Done counting 3 objects.
remote: Deltifying 3 objects.
remote: /3) done/3) done
remote: Total 3 (delta 0), reused 0 (delta 0)
Indexing 3 objects.
 100% (3/3) done
% cd foo
% echo bar >> foo
% git commit -a -m bar
Created commit e1179a3bf842ddcf4643740a396b46ce7ebd4ada
 1 files changed, 1 insertions(+), 0 deletions(-)
% git push
updating 'refs/heads/master'
  from fee4efae4f3b98cce0fe85efc746291157fffbcd
  to   e1179a3bf842ddcf4643740a396b46ce7ebd4ada
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)
unpack unpacker exited with error code
ng refs/heads/master n/a (unpacker error)

Re: git-push through git protocol

[Bill Lear]

On Sunday, January 21, 2007 at 19:31:44 (-0600) Bill Lear writes:
>...
>I applied the patches ...

I neglected to say that these patches were applied to the latest
1.5.0-rc2 code.  Sorry for the slip.


Bill

Re: [PATCH] Make sure git_connect() always give two file descriptors.

[Linus Torvalds]

On Sun, 21 Jan 2007, Junio C Hamano wrote:
>
> Earlier, git_connect() returned the same fd when the destination
> was remote (i.e.  we used socket to communicate with it) and two
> separate fds when the destination was local (i.e. we used
> pipe(2)).

Actually, to be strictly correct, we returned the same fd when

 - we used git:// and were not proxying

and we returned two different fd's for all other cases (ie local, ssh, 
proxy-git).

So it's not really about "remote" vs "local", since ssh in particular is 
mostly remote too, but since we used pipes to connect with ssh, it acted 
the same way as the local case (which also used pipes to connect to the 
local processes).

And git:// with proxy support also ended up using pipes (for the proxy 
process), which is why you _only_ saw this with the raw direct TCP git:// 
case.

Or something like that.-

		Linus

Re: git-push through git protocol

[Linus Torvalds]

On Sun, 21 Jan 2007, Bill Lear wrote:
> 
> I applied the patches and I get failure.  I have appended the entire
> test case after my sig.  The last part reads:

Ok, that's different. It worked for me, several times. As far as I can 
tell, the biggest thing is just a difference in OS and the fact that I'm 
not running the git daemon from xinetd, but directly by hand as myself.

> % git push
> updating 'refs/heads/master'
>   from fee4efae4f3b98cce0fe85efc746291157fffbcd
>   to   e1179a3bf842ddcf4643740a396b46ce7ebd4ada
> Generating pack...
> Done counting 5 objects.
> Result has 3 objects.
> Deltifying 3 objects.
>  100% (3/3) done
> Writing 3 objects.
>  100% (3/3) done
> Total 3 (delta 0), reused 0 (delta 0)
> unpack unpacker exited with error code
> ng refs/heads/master n/a (unpacker error)

Umm. Your git daemon is probably running as "nobody", and simply doesn't 
have write permissions to the archive, does it?

> % cat /etc/xinet.d/git-daemon
> service git
> {
>         user            = nobody

iow, I think you simply need to make sure that git-daemon will have write 
permission to the thing. Either by making the whole repository writable by 
nobody, or by running git-daemon as the proper user.

		Linus

Re: git-push through git protocol

[Martin Langhoff]

On 1/22/07, Linus Torvalds <torvalds@osdl.org> wrote:
> Umm. Your git daemon is probably running as "nobody", and simply doesn't
> have write permissions to the archive, does it?
>
> > % cat /etc/xinet.d/git-daemon
> > service git
> > {
> >         user            = nobody
>
> iow, I think you simply need to make sure that git-daemon will have write
> permission to the thing. Either by making the whole repository writable by
> nobody, or by running git-daemon as the proper user.

Whereby I personaly run back quickly to cover under my git-over-ssh
safety blanket.

:-)


martin

Re: git-push through git protocol

[Linus Torvalds]

On Mon, 22 Jan 2007, Martin Langhoff wrote:

> On 1/22/07, Linus Torvalds <torvalds@osdl.org> wrote:
> > Umm. Your git daemon is probably running as "nobody", and simply doesn't
> > have write permissions to the archive, does it?
> > 
> > > % cat /etc/xinet.d/git-daemon
> > > service git
> > > {
> > >         user            = nobody
> > 
> > iow, I think you simply need to make sure that git-daemon will have write
> > permission to the thing. Either by making the whole repository writable by
> > nobody, or by running git-daemon as the proper user.
> 
> Whereby I personaly run back quickly to cover under my git-over-ssh
> safety blanket.

Sure. 

I suspect that git-daemon is possibly easier and faster to set up in the 
kind of situation where you set up git instead of CVS inside a company, 
though.

In that situation, you could just say: "machine X is the central CVS 
repository, and now it also contains a set of git repositories, all owned 
by nobody:nobody".

That way, you basically get the exact same situation as you had with CVS, 
with minimal setup.

If the alternative is some NFS thing, I'd take that writing git-daemon 
over shared NFS-access from everybody any day..

		Linus

Re: git-push through git protocol

[Bill Lear]

On Sunday, January 21, 2007 at 19:01:45 (-0800) Linus Torvalds writes:
>On Mon, 22 Jan 2007, Martin Langhoff wrote:
>> ...
>> Whereby I personaly run back quickly to cover under my git-over-ssh
>> safety blanket.
>
>Sure. 
>
>I suspect that git-daemon is possibly easier and faster to set up in the 
>kind of situation where you set up git instead of CVS inside a company, 
>though. ...

Another nice thing with the git protocol is that we can keep the
repository "interface" constant --- it's always "git://server/repo"
for us, even if we have the repo one day at /repos/git/repo, or later
decide to move it to /backedup/repos/git/repo.  All we have to do is
change the git-daemon file and point it at the new repo, and all the
developers' origin files need not change.  You can do this with
symlinks, I suppose, but after the third move, we really appreciated
the git mobility and disliked the litter of symlinks:-)


Bill

Re: git-push through git protocol

[Bill Lear]

On Sunday, January 21, 2007 at 17:52:22 (-0800) Linus Torvalds writes:
>...
>iow, I think you simply need to make sure that git-daemon will have write 
>permission to the thing. Either by making the whole repository writable by 
>nobody, or by running git-daemon as the proper user.

This now works:

% perl -pi -e 's/nobody/blear/' /etc/xinetd.d/git-daemon
% /etc/init.d/xinetd restart
% cd test/foo
% cat .git/remotes/origin
URL: git://blake/foo
Pull: refs/heads/master:refs/heads/origin
% git push
updating 'refs/heads/master'
  from fee4efae4f3b98cce0fe85efc746291157fffbcd
  to   73167c1dbcd08ef290f9ead5eef1808236e728b3
Generating pack...
Done counting 5 objects.
Result has 3 objects.
Deltifying 3 objects.
 100% (3/3) done
Writing 3 objects.
 100% (3/3) done
Total 3 (delta 0), reused 0 (delta 0)

Thanks for the help.


Bill