path: root/fetch-clone.c
AgeCommit message (Collapse)Author
2006-08-15use appropriate typedefsDavid Rientjes
Signed-off-by: David Rientjes <> Signed-off-by: Junio C Hamano <>
2006-08-03sideband: do not use color, just say "remote:"Junio C Hamano
... per suggestion by Andrew. Signed-off-by: Junio C Hamano <>
2006-08-01fetch/clone: mark messages from remote side stand out.Junio C Hamano
When dealing with a corrupt or out of sync remote repository, the user often gets error messages like this: error: refs/heads/devel does not point to a valid commit object! which leaves the user wondering if the breakage is on the local end or on the remote end. This is unnecessarily alarming. This patch changes the way we display messages received from the remote side over the git protocol sideband (i.e. stderr stream of the remote process). It shows them with blue background with white letters, but this presentation is subject to proposals of better ways from the list. The problem was pointed out by Andrew Morton. Signed-off-by: Junio C Hamano <>
2006-07-10Fix more typos, primarily in the codePavel Roskin
The only visible change is that git-blame doesn't understand "--compability" anymore, but it does accept "--compatibility" instead, which is already documented. Signed-off-by: Pavel Roskin <> Signed-off-by: Junio C Hamano <>
2006-06-21upload-pack/fetch-pack: support side-band communicationJunio C Hamano
This implements a protocol extension between fetch-pack and upload-pack to allow stderr stream from upload-pack (primarily used for the progress bar display) to be passed back. Signed-off-by: Junio C Hamano <>
2006-02-12Fix fetch-clone in the presense of signalsLinus Torvalds
We shouldn't fail a fetch just because a signal might have interrupted the read. Normally, we don't install any signal handlers, so EINTR really shouldn't happen. That said, really old versions of Linux will interrupt an interruptible system call even for signals that turn out to be ignored (SIGWINCH is the classic example - resizing your xterm would cause it). The same might well be true elsewhere too. Also, since receive_keep_pack() doesn't control the caller, it can't know that no signal handlers exist. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-02-12Make "git clone" pack-fetching download statistics betterLinus Torvalds
Average it out over a few events to make the numbers stable, and fix the silly usec->binary-ms conversion. Yeah, yeah, it's arguably eye-candy to keep the user calm, but let's do that right. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-02-11Make "git clone" less of a deathly quiet experienceLinus Torvalds
It used to be that "git-unpack-objects" would give nice percentages, but now that we don't unpack the initial clone pack any more, it doesn't. And I'd love to do that nice percentage view in the pack objects downloader too, but the thing doesn't even read the pack header, much less know how much it's going to get, so I was lazy and didn't. Instead, it at least prints out how much data it's gotten, and what the packing speed is. Which makes the user realize that it's actually doing something useful instead of sitting there silently (and if the recipient knows how large the final result is, he can at least make a guess about when it migt be done). So with this patch, I get something like this on my DSL line: [torvalds@g5 ~]$ time git clone clone-test Packing 188543 objects 48.398MB (154 kB/s) where even the speed approximation seems to be roughtly correct (even though my algorithm is a truly stupid one, and only really gives "speed in the last half second or so"). Anyway, _something_ like this is definitely needed. It could certainly be better (if it showed the same kind of thing that git-unpack-objects did, that would be much nicer, but would require parsing the object stream as it comes in). But this is big step forward, I think. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2006-01-14Exec git programs without using PATH.Michal Ostrowski
The git suite may not be in PATH (and thus programs such as git-send-pack could not exec git-rev-list). Thus there is a need for logic that will locate these programs. Modifying PATH is not desirable as it result in behavior differing from the user's intentions, as we may end up prepending "/usr/bin" to PATH. - git C programs will use exec*_git_cmd() APIs to exec sub-commands. - exec*_git_cmd() will execute a git program by searching for it in the following directories: 1. --exec-path (as used by "git") 2. The GIT_EXEC_PATH environment variable. 3. $(gitexecdir) as set in Makefile (default value $(bindir)). - git wrapper will modify PATH as before to enable shell scripts to invoke "git-foo" commands. Ideally, shell scripts should use the git wrapper to become independent of PATH, and then modifying PATH will not be necessary. [jc: with minor updates after a brief review.] Signed-off-by: Michal Ostrowski <> Signed-off-by: Junio C Hamano <>
2006-01-06trivial: retval of waitpid is not errnoAlex Riesen
...but is used as such and passed to strerror. Signed-off-by: Alex Riesen <> Signed-off-by: Junio C Hamano <>
2005-12-18fetch-pack: -k option to keep downloaded pack.Junio C Hamano
Split out the functions that deal with the socketpair after finishing git protocol handshake to receive the packed data into a separate file, and use it in fetch-pack to keep/explode the received pack data. We earlier had something like that on clone-pack side once, but the list discussion resulted in the decision that it makes sense to always keep the pack for clone-pack, so unpacking option is not enabled on the clone-pack side, but we later still could do so easily if we wanted to with this change. Signed-off-by: Junio C Hamano <>