On 31/05/17 21:10, Hector Santos wrote:
Hi, I am relatively new to GIT (coming from CVS and SVN) and I am trying to
setup "Git Daemon" on windows.
I got it working for Local network communications:
d:\local\wc5\testgit>git clone git://localhost/http clone10
Cloning into 'clone10'...
remote:
Duy Nguyen wrote:
> I wonder if we should make this "git/1.9.1" information more visible. We could
>
> 1) Always print it when cloning
> 2) Print it when cloning with -v (printing all capabilities with -v
> might not be a bad idea)
> 3) Include it in error messages when clone/fetch fails
I don't
On Tue, Feb 7, 2017 at 7:56 AM, Bob Proulx wrote:
> Bob Proulx wrote:
>> 17:20:40.590177 pkt-line.c:46 packet:clone<
>> 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band
>> side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed
Bob Proulx wrote:
> 17:20:40.590177 pkt-line.c:46 packet:clone<
> 34e7202270c381f4e5734180dc19426ce69f2e1e HEAD\0multi_ack thin-pack side-band
> side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed
> symref=HEAD:refs/heads/master agent=git/1.9.1
The evi
Duy Nguyen wrote:
> Jeff King wrote:
> > It depends on the git version on the server. The interesting code is in
> > upload-pack.c, which is spawned by git-daemon to serve a fetch or clone
> > request.
> >
> > See commit b790e0f67 (upload-pack: send shallow info over stdin to
> > pack-objects, 2014
Hello Johannes,
Thank you very much for the good hints here. They are very helpful.
Johannes Schindelin wrote:
> Assuming that you can rebuild your Git with debug symbols and without
> optimization (simply remove the -O2 from CFLAGS in the Makefile, I never
> had any luck with single-stepping in
On Tue, Jan 31, 2017 at 12:27 AM, Jeff King wrote:
> On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote:
>
>> However the problem driving me crazy is that this only fails this way
>> on one machine. Unfortunately failing on the machine I need to use.
>> If I try this same setup on any oth
On Sat, Jan 28, 2017 at 05:29:32PM -0700, Bob Proulx wrote:
> However the problem driving me crazy is that this only fails this way
> on one machine. Unfortunately failing on the machine I need to use.
> If I try this same setup on any other machine I try then there is no
> failure and it works o
Hi Bob,
On Sat, 28 Jan 2017, Bob Proulx wrote:
> And the server side says:
>
> [26071] Request upload-pack for '/test-project.git'
> [26071] fatal: Unable to create temporary file
> '/srv/git/test-project.git/shallow_xKwnvZ': Permission denied
> [26055] [26071] Disconnected (with error)
On Sat, 2016-11-26 at 12:09 -0500, Jeff King wrote:
> On Sat, Nov 26, 2016 at 03:03:48PM +0100, Mike Galbraith wrote:
>
> > git-daemon went broke on me post v2.9.3 due to binaries being installed
> > in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it
> > up, as does ln -s /usr
On Sat, Nov 26, 2016 at 03:03:48PM +0100, Mike Galbraith wrote:
> git-daemon went broke on me post v2.9.3 due to binaries being installed
> in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it
> up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon 'course,
> but thought
Hi Mike,
On Sat, 2016-11-26 at 15:03 +0100, Mike Galbraith wrote:
> Greetings,
>
> git-daemon went broke on me post v2.9.3 due to binaries being installed
> in /usr/lib/git, which is not in PATH. Reverting 650c449250d7 fixes it
> up, as does ln -s /usr/lib/git/git-daemon /usr/bin/git-daemon 'cou
On Tue, Feb 23, 2016 at 4:11 PM, Jason A. Donenfeld wrote:
> That's interesting. I didn't realize that even the smart protocol was
> not as efficient as HTTP
Can't type today. *as efficient as git://
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to maj
On Tue, Feb 23, 2016 at 11:51 AM, John Keeping wrote:
> On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> There's no license specified in the repo, it just says "All rights
> reserved" in the .c file. I'm sure you intend it to be open source, but
> it isn't unless a license is
On Tue, Feb 23, 2016 at 7:15 AM, Jeff King wrote:
>
> Yeah, the existence of HTTPS (and the fact that the same URL can be both
> anonymous and authenticated) is nice. Unfortunately, git-over-https is
> not as efficient as the other protocols, because it's not asynchronously
> bi-directional. It wo
On Tue, Feb 23, 2016 at 1:15 PM, Jeff King wrote:
> I looked into it once, but was unable to find any reasonably sized
> explanation of how to implement either the server or client side of
> websockets. :)
Wikipedia explained handshake in four paragraphs. Then you only have
to chew about ten page
On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> In case anyone else finds this useful, I wrote this:
>
> https://git.zx2c4.com/git-daemon-dummy/about/
>
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI. The purpose is to ph
On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> In case anyone else finds this useful, I wrote this:
>
> https://git.zx2c4.com/git-daemon-dummy/about/
>
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI.
Neat.
> The purpo
On Sun, Jun 09, 2013 at 02:47:57PM +0200, Bernhard R. Link wrote:
> * Ian Kumlien [130605 13:31]:
> > Yes, i agree, it's suboptimal but I for one would use getpwuid to get
> > the home directory of the executing user to avoid this - though i don't
> > know how portable it is (or if there is any ot
* Ian Kumlien [130605 13:31]:
> Yes, i agree, it's suboptimal but I for one would use getpwuid to get
> the home directory of the executing user to avoid this - though i don't
> know how portable it is (or if there is any other issues)
It's not only suboptimal but simply wrong. getpwuid gives at
On Wed, Jun 05, 2013 at 01:19:18PM +0200, Ian Kumlien wrote:
> > Older versions of git silently ignored errors reading config files, but
> > it was tightened in v1.8.1.1, as there can be quite serious implications
> > to failing to read expected config (e.g., imagine transfer.fsckobjects,
> > or r
On Wed, 05 Jun 2013 13:19:18 +, Ian Kumlien wrote:
...
> Well, I have no idea of how to control HOME in xinetd - access to the
> machine is limited and x doesn't give that much access (nothing really
> important is actually stored in /root)
Make xinetd execute '/usr/bin/env HOME=/home/yourstru
On Tue, Jun 04, 2013 at 12:08:15PM -0400, Jeff King wrote:
> On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote:
>
> > Due to the earlier problem I upgraded git on all machines
> > and eneded up with a ubunut machine running in to problems.
> >
> > I started getting errors like:
> > "fa
Jeff King writes:
> On Tue, Jun 04, 2013 at 12:10:25PM -0700, Jonathan Nieder wrote:
>
>> >> However, since changing user id and leaving $HOME is so common, there is
>> >> a patch under consideration to loosen the check only for the case of
>> >> EACCES on files in $HOME. That commit is 4698c8f (
On Tue, Jun 04, 2013 at 12:10:25PM -0700, Jonathan Nieder wrote:
> >> However, since changing user id and leaving $HOME is so common, there is
> >> a patch under consideration to loosen the check only for the case of
> >> EACCES on files in $HOME. That commit is 4698c8f (config: allow
> >> inacces
Jonathan Nieder writes:
> I could be remembering wrong, but I thought it was not so much "under
> consideration" as "accepted for 1.8.4". I haven't heard any
> compelling reasons not to apply it.
>
> Would it would make sense against earlier releases as well?
True; the patch is queued on a topi
Johannes Sixt wrote:
> Am 04.06.2013 18:08, schrieb Jeff King:
>> However, since changing user id and leaving $HOME is so common, there is
>> a patch under consideration to loosen the check only for the case of
>> EACCES on files in $HOME. That commit is 4698c8f (config: allow
>> inaccessible conf
Am 04.06.2013 18:08, schrieb Jeff King:
> Older versions of git silently ignored errors reading config files, but
> it was tightened in v1.8.1.1, as there can be quite serious implications
> to failing to read expected config (e.g., imagine transfer.fsckobjects,
> or receive.deny* is ignored).
>
>
On Tue, Jun 04, 2013 at 04:13:14PM +0200, Ian Kumlien wrote:
> Due to the earlier problem I upgraded git on all machines
> and eneded up with a ubunut machine running in to problems.
>
> I started getting errors like:
> "fatal: protocol error: bad line length character: fata"
>
> Which after so
Right, --informative-errors does make it better;)
Actually the CWD for the access-hook is not where the hook script is,
but inside the .git folder of the target repo. GTK.
and yes, definitely some documentation improvements needed;)
Thanks!
On Mon, Jun 3, 2013 at 3:05 PM, Antoine Pelisse wrote
On Mon, Jun 3, 2013 at 8:02 PM, Eugene Sajine wrote:
> Would you be able to advise how this should be done?
> I don't get the error message (i mean the output of pwd) if i do this:
>
> echo `pwd`
> exit 1
>
> What should it be?
Actually, after digging into the code, it looks like you need to call
> - Your log file might not be located where you expect, you should use
> absolute path to dump text
You were right! The problem was with the script itself - the log file
not being specified with absolute path! Stupid me!
...
> - The documentation says you can print one line before a failure, als
On Fri, May 31, 2013 at 10:22 PM, Eugene Sajine wrote:
> and trying to perform some operations like fetch or push. It is cloned
> and fetches and pushes successfully.
> The problem is that the file test_hook_out.txt doesn't have anything
> in it after the execution, So the hook doesn't seem to wor
Anybody? Any ideas?
Thanks in advance!
Eugene
On Fri, May 31, 2013 at 4:22 PM, Eugene Sajine wrote:
> Hi,
>
> I'm trying to test this new feature and having problems getting any
> results in the following scenario:
>
> i have a repo in local folder
>
> /home/users/myuser/repos/projectA/.git
>
>
Sunday 12 August 2005 04:13 Petr Baudis wrote:
> Hello,
>
> is anyone actually using the git daemon in practice, now that the
> other transfer methods can deal with packs? I ask since I wonder if I
> should actually bother with adding support for it to cg-pull.
Sorry for the very late answer -
On Fri, 15 Jul 2005, H. Peter Anvin wrote:
>
> Since it can be run as a sequestered user, and we now have plenty of CPU
> horsepower on the download servers, it seems like it should be an
> entirely sane thing to do.
Goodie.
> Is this thing meant to be run from inetd, or is it a "listen and
Linus Torvalds wrote:
What I'd ask people to check is how comfortable for example kernel.org
would be to have one machine that runs this kind of service? I've tried
very hard to set it up so that it doesn't have any security issues: the
daemon can be run as "nobody", and it shouldn't ever eve
On Wed, 13 Jul 2005, Linus Torvalds wrote:
>
> Anyway, this would be a _wonderful_ interface for read-only updates, ie
> people pulling from my (and other peoples) git repositories.
I guess I should say what the interface is, so that people don't have to
read the sources to find out..
On the
38 matches
Mail list logo
