SZEDER Gábor writes:
> After 'start_git_daemon' starts 'git daemon' (note the space in the
> middle) in the background, it saves the background process' PID, so
> the daemon can be stopped at the end of the test script. However,
> 'git-daemon'
After 'start_git_daemon' starts 'git daemon' (note the space in the
middle) in the background, it saves the background process' PID, so
the daemon can be stopped at the end of the test script. However,
'git-daemon' is not a builtin but a dashed external command,
From: Johannes Schindelin
Use 'test_atexit' to run cleanup commands to stop 'git-daemon' at the
end of the test script or upon interrupt or failure, as it is shorter,
simpler, and more robust than registering such cleanup commands in the
trap on EXIT in the test scripts.
Not
On Sat, Mar 02, 2019 at 10:21:00PM +0100, Johannes Schindelin wrote:
> Do you want to turn these two patches into a proper patch series?
> Otherwise I can take care of it, probably this Monday or Tuesday.
Here they are. The old email sending the first one actually had a typo
(it sent "" inste
Hi Junio,
On Sun, 3 Mar 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > But for git-fetch, our primary purpose is receiving data and writing it
> > to disk. We should be checking all of our write()s already, and SIGPIPE
> > is just confusing.
>
> Yup, sounds like a very sensible argument
Jeff King writes:
> But for git-fetch, our primary purpose is receiving data and writing it
> to disk. We should be checking all of our write()s already, and SIGPIPE
> is just confusing.
Yup, sounds like a very sensible argument.
> So I'd actually be fine with just declaring that certain comman
Hi Peff,
On Fri, 1 Mar 2019, Jeff King wrote:
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index b620fd54b4..4ba63d5ac6 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -1556,7 +1556,9 @@ static int fetch_one(struct remote *remote, int argc,
> const char **argv, int pru
>
>
On Fri, Mar 01, 2019 at 04:02:22PM +0100, Johannes Schindelin wrote:
> > I think that patch does the write_or_die conversion to handle EPIPE, but
> > it would still need to turn off SIGPIPE for the whole process.
> >
> > So you'd also need to stick a:
> >
> > sigchain_push(SIGPIPE, SIG_IGN);
>
Hi Peff,
On Fri, 8 Feb 2019, Jeff King wrote:
> On Fri, Feb 08, 2019 at 10:28:12AM +0100, Johannes Schindelin wrote:
>
> > On Fri, 8 Feb 2019, Johannes Schindelin wrote:
> >
> > > I just had a look at the patch you provided below (for some reason, my
> > > previous search on public-inbox only t
On Fri, Feb 08, 2019 at 10:28:12AM +0100, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 8 Feb 2019, Johannes Schindelin wrote:
>
> > I just had a look at the patch you provided below (for some reason, my
> > previous search on public-inbox only turned up Gábor's mail to which you
> > respond
;;
GIT_TEST_GETTEXT_POISON)
export GIT_TEST_GETTEXT_POISON=YesPlease
--
2.20.1.940.g8404bb2d1a
-- >8 --
> > > What it boils down to is this sequence:
> > >
> > > - The test first prepares a repository containing a corrupt pack,
> > >
it upload-pack'; how could it,
> > > it doesn't even get as far to receive upload-pack's ERR
> > > pkt-line.
> > >
> > > The test only checks that 'git fetch' fails, but it doesn't
> > > check whether
hat 'git fetch' fails, but it doesn't
> > check whether it failed with the right error message, so the
> > test still succeeds. Had it checked the error message as well,
> > we most likely had noticed this issue already, it doesn't happen
>
is a symptom
> > a real bug in Git affecting other platforms as well, but these tests
> > are too lax to catch it.
I am seeing this very frequently now, as it feels like failing in the
Azure Pipeline about half of the time.
The symptom is this:
-- snip --
++ cp -R '/Users/vsts/a
Jeff King writes:
> Yep, this looks good to me. Thanks for being extra careful with the
> read/printf bits!
>
> Looks like Junio already queued a99653a9b6 (Revert "t/lib-git-daemon:
> record daemon log", 2018-12-28) on the tip of tg/t5570-drop-racy-test,
> but that
On Sun, Jan 06, 2019 at 05:53:10PM +, Thomas Gummerer wrote:
> This reverts commit 314a73d658 (t/lib-git-daemon: record daemon log,
> 2018-01-25), which let tests use the output of git-daemon.
>
> The previous commit removed the last user of deamon.log in the tests,
> there&#
This reverts commit 314a73d658 (t/lib-git-daemon: record daemon log,
2018-01-25), which let tests use the output of git-daemon.
The previous commit removed the last user of deamon.log in the tests,
there's no good way to make checking for output in the log
race-proof. Revert this commit as
On Mon, Nov 26, 2018 at 09:03:37PM +0100, SZEDER Gábor wrote:
> Test scripts checking 'git daemon' stop the daemon with a TERM signal,
> and the 'stop_git_daemon' helper checks the daemon's exit status to
> make sure that it indeed died because of that sign
Test scripts checking 'git daemon' stop the daemon with a TERM signal,
and the 'stop_git_daemon' helper checks the daemon's exit status to
make sure that it indeed died because of that signal.
This check is bogus since 03c39b3458 (t/lib-git-daemon: use
test_match_sig
test_expect_success ...
#
-# stop_git_daemon
# test_done
test_tristate GIT_TEST_GIT_DAEMON
@@ -43,7 +42,7 @@ start_git_daemon() {
mkdir -p "$GIT_DAEMON_DOCUMENT_ROOT_PATH"
- trap 'code=$?; stop_git_daemon; (exit $code); die' EXIT
+ test_atexit 'sto
On Tue, Aug 14, 2018 at 06:32:47PM -0400, Jeff King wrote:
> I suspect the (largely untested) patch below would make your test
> problems go away. Or instead, we could simply add sigpipe=ok to the
> test_must_fail invocation, but I agree with you that the current
> behavior on OS X is not ideal (t
the right error message, so the
> test still succeeds. Had it checked the error message as well,
> we most likely had noticed this issue already, it doesn't happen
> all that rarely.
Hmm. Traditionally we did not send ERR as part of upload-pack at all. It
was the m
e too lax to catch it.
>
> What it boils down to is this sequence:
>
> - The test first prepares a repository containing a corrupt pack,
> ready to be server via 'git daemon'.
>
> - Then the test runs 'test_must_fail git fetch ', which connects
>
is a symptom
a real bug in Git affecting other platforms as well, but these tests
are too lax to catch it.
What it boils down to is this sequence:
- The test first prepares a repository containing a corrupt pack,
ready to be server via 'git daemon'.
- Then the test runs 't
Hi,
On Fri, 20 Jul 2018, brian m. carlson wrote:
> On Fri, Jul 20, 2018 at 05:51:46PM -0400, Jeffrey Walton wrote:
>
> > (If anyone is interested in first class Solaris support then I am
> > happy to help. The patch set needed for the platform has been stable
> > for the last couple of years).
>
On Fri, Jul 20, 2018 at 05:51:46PM -0400, Jeffrey Walton wrote:
> Sorry about the late reply. I meant to reply this morning.
>
> My shell script to patch things on Solaris was the cause of the problem.
Glad to hear you got it figured out.
> (If anyone is interested in first class Solaris support
es. This appears to be a new
>> issue. It was not present in 2.17.1.
>>
>> gmake: *** No rule to make target `git-daemon'. Stop.
>> gmake: *** Waiting for unfinished jobs
>> Failed to build Git
>>
>> There does not appear to be an op
rule to make target `git-daemon'. Stop.
> gmake: *** Waiting for unfinished jobs
> Failed to build Git
Like others, I don't really have an idea on how this could have
happened. But perhaps "gmake -d git-daemon" could be enlightening?
Mine has:
[...]
Cons
gmake: *** No rule to make target `git-daemon'. Stop.
> gmake: *** Waiting for unfinished jobs
> Failed to build Git
>
> There does not appear to be an option to control building the daemon:
>
> $ ./configure --help | grep -i daemon
> $
>
On Thu, Jul 19, 2018 at 9:37 PM Jeffrey Walton wrote:
> I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
> the following when building from sources. This appears to be a new
> issue. It was not present in 2.17.1.
>
> gmake: *** No rule to make t
Hi Everyone,
I'm working from the 2.18 tarball on Solaris 11.3 x86_64. I'm catching
the following when building from sources. This appears to be a new
issue. It was not present in 2.17.1.
gmake: *** No rule to make target `git-daemon'. Stop.
gmake: *** Waiting for
The test 'no-op fetch without "-v" is quiet' in 't5570-git-daemon.sh'
fails when the test script is run with '-x' tracing (and using a shell
other than a Bash version supporting BASH_XTRACEFD). The reason for
the failure is that the test checks the emptiness of a subshell's
stderr, which includes
On Thu, Jan 25, 2018 at 10:46:51AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > This series fixes two off-by-one errors in git-daemon noticed by Michael
> > (who then nerd-sniped me into fixing them). It also improves
> > git-daemon's verbose logging of e
On Thu, Jan 25, 2018 at 12:56:47PM +0100, Lucas Werkmeister wrote:
> > Let's dump the log into a file, as well, so that future
> > tests can check the log. There are two subtleties worth
> > calling out here:
> >
> > - we replace "cat" with a subshell loop around "read" to
> > ensure that t
Jeff King writes:
> This series fixes two off-by-one errors in git-daemon noticed by Michael
> (who then nerd-sniped me into fixing them). It also improves
> git-daemon's verbose logging of extended attributes, and beefs up the
> tests a bit.
>
> Before anyone gets ex
On 25.01.2018 01:55, Jeff King wrote:
> When we start git-daemon for our tests, we send its stderr
> log stream to a named pipe. We synchronously read the first
> line to make sure that the daemon started, and then dump the
> rest to descriptor 4. This is handy for debugging test
&
ions which can be used to
manually conduct a git-protocol conversation with a remote
git-daemon:
1. To connect to a remote git-daemon, we need something
like "netcat". But not everybody will have netcat. And
even if they do, the behavior with respect to
half-duplex shutd
When we start git-daemon for our tests, we send its stderr
log stream to a named pipe. We synchronously read the first
line to make sure that the daemon started, and then dump the
rest to descriptor 4. This is handy for debugging test
output with "--verbose", but the tests themselves ca
This series fixes two off-by-one errors in git-daemon noticed by Michael
(who then nerd-sniped me into fixing them). It also improves
git-daemon's verbose logging of extended attributes, and beefs up the
tests a bit.
Before anyone gets excited, no, these aren't security-interesting
e
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 '
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: Counting obj
This test just checks that old clients can clone and fetch
from a newer git-daemon. The opposite should also be true,
but it's hard to test ancient versions of git-daemon because
they lack basic options like "--listen".
Note that we have to make a slight tweak to the
lib-git-dae
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
gressive about disabling
> the packaged version and hopefully find out which one.
I did and of course it is /usr/bin/git-upload-pack and if I disable
that binary then git-daemon no longer operates.
error: cannot run upload-pack: No such file or directory
But shouldn't it find git-upload-p
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 in
-stepping in gdb when compiled with -O2), you
I always debug with -g and without -O because otherwise it leads to a
lot of confusion. But git-daemon is a forking daemon which makes
debugging it with the debugger somewhere more default and requiring
more setup to debug past the fork points. As you
y this same setup on any other machine I try then there is no
>> failure and it works okay. Therefore I conclude that in the failing
>> case it is trying to write a shallow_XX file in the repository but
>> in all of the passing cases it does not. I browsed through the
>>
and it works okay. Therefore I conclude that in the failing
> case it is trying to write a shallow_XX file in the repository but
> in all of the passing cases it does not. I browsed through the
> git-daemon source but couldn't deduce the flow yet.
>
> Does anyone know wh
6055] [26071] Disconnected (with error)
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 gdb when compiled with -O2), you
could attach gdb to the git-daemon and/or upload
I am trying to understand a problem with shallow checkouts through the
git-daemon. The server side fails trying to create a shallow_XX
file in the repository. But of course it can't due to no permissions
from the git-daemon user.
However the problem driving me crazy is that this only
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
>
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 '
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
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 'course,
but thought I should report it, since it used to work without
ed 2016-06-30),
>> Trying to install a subset of Git packages (roughly, all those listed
>> in git-all, except CVS-related packages)
>> Install of package git-daemon-run (version 1:2.9.3-1) fails, dpkg
>> reporting error
>
> The git-daemon-run package is entirely a Debia
packages)
> Install of package git-daemon-run (version 1:2.9.3-1) fails, dpkg
> reporting error
The git-daemon-run package is entirely a Debian creation, and has more
to do with "runit" than it does with "git daemon" itself. In particular,
your problem:
> Assumed cause:
&
Hi,
Not really a bad bug, apparently just one little detail...
Symptoms:
On a fresh new install of Debian "Stretch" (8.5 alpha7, dated 2016-06-30),
Trying to install a subset of Git packages (roughly, all those listed
in git-all, except CVS-related packages)
Install of package git-
When git-daemon exits, we expect it to be with the SIGTERM
we just sent it. If we see anything else, we'll complain.
But our check against exit code "143" is not portable. For
example:
$ ksh93 t5570-git-daemon.sh
[...]
error: git daemon exited with status: 271
We can fi
On Tue, May 31, 2016 at 04:04:00PM -0700, Junio C Hamano wrote:
> The "git daemon" test checks with what status the daemon exits when
> we terminate it, and we expect that we can observe death by SIGTERM.
>
> We forgot that ksh adds 256, unlike 128 that are used by other
The "git daemon" test checks with what status the daemon exits when
we terminate it, and we expect that we can observe death by SIGTERM.
We forgot that ksh adds 256, unlike 128 that are used by other POSIX
shells, to the signal number that caused the process to die when
coming up wit
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
t
> it isn't unless a license is specified.
https://git.zx2c4.com/git-daemon-dummy/commit/?id=a7ebbf5ab63cb2e95c38a58197cd2805a2deb56f
There you go.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majo
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
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
Hi folks,
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 phase out git-daemon in
favor of more secure TLS/HTTPS endpoints.
Johannes Schindelin writes:
>> > diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
>> > @@ -23,6 +23,11 @@ then
>> > +if ! test_have_prereq PIPE
>>
>> Maybe:
>>
>> if test_have_prereq !PIPE
>>
>> ?
>
> Darn. Of course I only looked for '! .*MINGW', but I should have looked
> for '! te
Hi Eric,
On Thu, 28 Jan 2016, Eric Sunshine wrote:
> On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
> wrote:
> > The Git daemon tests create a FIFO first thing and will hang if said
> > FIFO is not available.
> >
> > This is a problem with Git for Windo
On Wed, Jan 27, 2016 at 11:19 AM, Johannes Schindelin
wrote:
> The Git daemon tests create a FIFO first thing and will hang if said
> FIFO is not available.
>
> This is a problem with Git for Windows, where `mkfifo` is an MSYS2
> program that leverages MSYS2's POSIX emulati
The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.
This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that
The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.
This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that
The Git daemon tests create a FIFO first thing and will hang if said
FIFO is not available.
This is a problem with Git for Windows, where `mkfifo` is an MSYS2
program that leverages MSYS2's POSIX emulation layer, but
`git-daemon.exe` is a MINGW program that has not the first clue about
that
On Thu, May 29, 2014 at 01:36:14PM +0200, Stepan Kasal wrote:
> Signed-off-by: Stepan Kasal
> ---
>
> Hi,
> mingw does not have FIFOs, so it cannot run git-daemon tests.
Thanks. I took a peek at the mkfifo call here. It is used to make sure
the daemon has started before w
Signed-off-by: Stepan Kasal
---
Hi,
mingw does not have FIFOs, so it cannot run git-daemon tests.
Stepan
t/lib-git-daemon.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index bc4b341..9b1271c 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib
>
> For now I'm trying to do the following:
>
> access-hook.bash has:
>
> delayed-notify.bash $@ &
>
> delayed-notify.bash has:
>
> sleep 10
> ...
> curl ...
>
> I'm expecting access-hook to spawn new process and return without
> waiting for it to finish to let the service to do its job. But when i
Eugene Sajine writes:
>> So even if we feed the exit status of the service process to the
>> hook script specified by the --post-service-hook, it does not tell
>> the script if the service "succeeded" in that sense.
>
> I see what you're saying.
> In my particular use case I can work around that
On Thu, Sep 12, 2013 at 6:20 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Eugene Sajine writes:
>>
>>> So are you really sure that it is a non-starter to have
>>> --before-service/--after-service options for access-hook?
>>
>> Given the definition of "--access-hook" in "git help daemo
Junio C Hamano writes:
> Eugene Sajine writes:
>
>> So are you really sure that it is a non-starter to have
>> --before-service/--after-service options for access-hook?
>
> Given the definition of "--access-hook" in "git help daemon":
>
> --access-hook=::
> Every time a client co
On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine wrote:
> Junio,
>
> Thanks for the clarification! Your solution does look better.
>
> For now though i think i will have to delay the notification somehow
> and let the service finish first then notify the server.
>
> Thanks again!
>
> Eugene
>
>
> On
Junio,
Thanks for the clarification! Your solution does look better.
For now though i think i will have to delay the notification somehow
and let the service finish first then notify the server.
Thanks again!
Eugene
On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano wrote:
> Eugene Sajine writ
Eugene Sajine writes:
> So are you really sure that it is a non-starter to have
> --before-service/--after-service options for access-hook?
Given the definition of "--access-hook" in "git help daemon":
--access-hook=::
Every time a client connects, first run an external command
On Thu, Sep 12, 2013 at 3:15 PM, Junio C Hamano wrote:
> Eugene Sajine writes:
>
>> Is it possible to have access-hook to be executed after receive?
>
> The whole point of access-hook is to allow it to decide whether the
> access is allowed or not, so that is a non-starter.
>
> A notification _af
Eugene Sajine writes:
> Is it possible to have access-hook to be executed after receive?
The whole point of access-hook is to allow it to decide whether the
access is allowed or not, so that is a non-starter.
A notification _after_ successful push update is usually done via
the post-receive hoo
Hi,
We are serving repos in closed netwrok via git protocol. We are using
git-daemon access hook (thank you very much for such a great feature)
in order to create push notifications for Jenkins.
I.e. upon the push the access-hook is called and then the curl command
is created and executed. As we
On Sat, 22 Jun 2013 23:21:03 +, Junio C Hamano wrote:
...
> Are there examples of other daemon programs outside Git that have
> this particular support to help such inetd implementations?
Unfortunately I only know one server that exclusively uses this
interface, and isn't even capable of runni
On Sat, Jun 22, 2013 at 1:41 PM, Andreas Krey wrote:
> diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
> index 223f731..007d3fc 100644
> --- a/Documentation/git-daemon.txt
> +++ b/Documentation/git-daemon.txt
> @@ -113,6 +113,10 @@ OPTIONS
> Log to syslog instead o
Andreas Krey writes:
> Some people run inetds that collect stderr of the spawned programs.
> Give them 'git-daemon --inetd --no-syslog' to keep error output
> on stderr.
>
> Signed-off-by: Andreas Krey
> ---
Are there examples of other daemon programs outside G
Some people run inetds that collect stderr of the spawned programs.
Give them 'git-daemon --inetd --no-syslog' to keep error output
on stderr.
Signed-off-by: Andreas Krey
---
Documentation/git-daemon.txt | 4
daemon.c | 14 +++---
2 files changed, 15
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
I started getting errors like:
> > "fatal: protocol error: bad line length character: fata"
> >
> > Which after some head scratching caused me to tell xinetd to directly
> > launch git-daemon, eventually it worked fine, but i did get this error
> > message:
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
#x27;s not yet in any
> released version of git, though.
>
> In the meantime, the suggested workaround is to set $HOME for the
> git-daemon user, rather than loosening /root.
I've a PHP script in ~/public_html that runs git. Without the mentioned
patch, the script bails out due to th
1 - 100 of 159 matches
Mail list logo
