user/sven/git.git/upload-pack.c, branch v1.5.4.4

upload-pack: Initialize the exec-path.

2008-02-13T20:04:01Z

Since git-upload-pack has to spawn git-pack-objects, it has to make sure that the latter can be found in the PATH. Without this patch an attempt to clone or pull via ssh from a server fails if the git tools are not in the standard PATH on the server even though git clone or git pull were invoked with --upload-pack=/path/to/git-upload-pack. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

upload-pack: Use finish_{command,async}() instead of waitpid().

2007-11-06T06:47:28Z

upload-pack spawns two processes, rev-list and pack-objects, and carefully monitors their status so that it can report failure to the remote end. This change removes the complicated procedures on the grounds of the following observations: - If everything is OK, rev-list closes its output pipe end, upon which pack-objects (which reads from the pipe) sees EOF and terminates itself, closing its output (and error) pipes. upload-pack reads from both until it sees EOF in both. It collects the exit codes of the child processes (which indicate success) and terminates successfully. - If rev-list sees an error, it closes its output and terminates with failure. pack-objects sees EOF in its input and terminates successfully. Again upload-pack reads its inputs until EOF. When it now collects the exit codes of its child processes, it notices the failure of rev-list and signals failure to the remote end. - If pack-objects sees an error, it terminates with failure. Since this breaks the pipe to rev-list, rev-list is killed with SIGPIPE. upload-pack reads its input until EOF, then collects the exit codes of the child processes, notices their failures, and signals failure to the remote end. - If upload-pack itself dies unexpectedly, pack-objects is killed with SIGPIPE, and subsequently also rev-list. The upshot of this is that precise monitoring of child processes is not required because both terminate if either one of them dies unexpectedly. This allows us to use finish_command() and finish_async() instead of an explicit waitpid(2) call. The change is smaller than it looks because most of it only reduces the indentation of a large part of the inner loop. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano

upload-pack: Run rev-list in an asynchronous function.

2007-10-21T05:30:42Z

This gets rid of an explicit fork(). Since upload-pack has to coordinate two processes (rev-list and pack-objects), we cannot use the normal finish_async(), but have to monitor the process explicitly. Hence, there are no changes at this front. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

upload-pack: Move the revision walker into a separate function.

2007-10-21T05:30:41Z

This allows us later to use start_async() with this function, and at the same time is a nice cleanup that makes a long function (create_pack_file()) shorter. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

upload-pack: Use start_command() to run pack-objects in create_pack_file().

2007-10-21T05:30:40Z

This gets rid of an explicit fork/exec. Since upload-pack has to coordinate two processes (rev-list and pack-objects), we cannot use the normal finish_command(), but have to monitor the processes explicitly. Hence, the waitpid() call remains. Signed-off-by: Johannes Sixt Signed-off-by: Shawn O. Pearce

Even more missing static

2007-06-08T09:54:57Z

Signed-off-by: Junio C Hamano

War on whitespace

2007-06-07T07:04:01Z

This uses "git-apply --whitespace=strip" to fix whitespace errors that have crept in to our source files over time. There are a few files that need to have trailing whitespaces (most notably, test vectors). The results still passes the test, and build result in Documentation/ area is unchanged. Signed-off-by: Junio C Hamano

git-upload-pack: make sure we close unused pipe ends

2007-03-28T00:05:12Z

Right now, we don't close the read end of the pipe when git-upload-pack runs git-pack-object, so we hang forever (why don't we get SIGALRM?) instead of dying with SIGPIPE if the latter dies, which seems to be the norm if the client disconnects. Thanks to Johannes Schindelin for pointing out where this close() needed to go. This patch has been tested on kernel.org for several weeks and appear to resolve the problem of git-upload-pack processes hanging around forever. Signed-off-by: H. Peter Anvin Signed-off-by: Junio C Hamano

Merge branch 'js/fetch-progress' (early part)

2007-03-05T01:31:21Z

* 'js/fetch-progress' (early part): Fixup no-progress for fetch & clone fetch & clone: do not output progress when not on a tty Conflicts: git-fetch.sh

Fixup no-progress for fetch & clone

2007-02-24T08:26:18Z

The intent of the commit 'fetch & clone: do not output progress when not on a tty' was to make fetching and cloning less chatty when output was not redirected (such as in a cron job). However, there was a serious thinko in that commit. It assumed that the client _and_ the server got this update at the same time. But this is obviously not the case, and therefore upload-pack died on seeing the option "--no-progress". This patch fixes that issue by making it a protocol option. So, until your server is updated, you still see the progress, but once the server has this patch, it will be quiet. A minor issue was also fixed: when cloning, the checkout did not heed no_progress. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano