| Age | Commit message (Collapse) | Author |
|---|
|
The program is not used by git-clone since git-fetch-pack was extended
to allow its caller do what git-clone-pack alone did, and git-clone was
updated to use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This makes fetch-pack also report the progress of packing part.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
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 master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 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 <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
While we are at it, give fully spelled --keep to fetch-pack.
Also give --quiet in addition to -q to fetch-pack as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
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 <junkio@cox.net>
|
|
clone-pack had some logic to accept subset of remote refs from
the command line and clone from there. However, it was never
used in practice and its problems were not found out so far.
This commit changes the command to output the object names of
refs to the standard output instead of making a clone of the
remote repository when explicit <head> parameters are given; the
output format is the same as fetch-pack.
The traditional behaviour of cloning the whole repository by
giving no explicit <head> parameters stays the same.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
These are whole-tree operations and there is not much point
making them operable from within a subdirectory, but it is easy
to do so, and using setup_git_directory() upfront helps git://
proxy specification picked up from the correct place.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
FAT -- like Coda -- does not like cross-directory hard links. To be
precise, FAT does not like links at all. But links are not needed either.
So get rid of them.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This deprecates --keep and -q flags and always keeps the pack
sent from the remote site. Corresponding configuration
variables are also removed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This allows the remote side (most notably, upload-pack) to show
additional information without affecting the downloader. Peek-remote
does not ignore them -- this is to make it useful for Pasky's
automatic tag following.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
Using git-check-ref-format, make sure we do not create refs with
funny names when cloning from elsewhere (clone-pack), fast forwarding
local heads (git-fetch), or somebody pushes into us (receive-pack).
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
With new option --keep, or a configuration item clone.keeppack (we
need a better name, or start allowing dash,"clone.keep-pack"), the packed
data downloaded while cloning is saved as a pack in .git/objects/pack/
locally, with index generated for it with git-index-pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
With new option --keep, or a configuration item clone.keeppack (we
need a better name, or start allowing dash,"clone.keep-pack"), the packed
data downloaded while cloning is saved as a pack in .git/objects/pack/
locally, with index generated for it with git-index-pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
This was the last instance of symlink() in coreish part.
Signed-off-by: Junio C Hamano <junkio@cox.net>
|
|
GCC's format __attribute__ is good for checking errors, especially
with -Wformat=2 parameter. This fixes most of the reported problems
against 2005-08-09 snapshot.
|
|
It really just boils down to one "get_remote_heads()" function, and a
common "struct ref" structure definition.
|
|
Cleans a small cut-and-paste mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
While adding the documentation for these two commands, I noticed
that the name of the program on the other end (git-upload-pack)
is already almost configurable but git-clone-pack lacked command
line parameter parsing to actually use anything but default, so
I introduced --exec= like other remote commands while I was at it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
Same issue as git-fetch-pack.
|
|
Maybe you don't want the progress report.
|
|
Local function that wasn't marked static
|
|
The function write_one_ref() is passed the list of refs received
from the other end, which was obtained by directory traversal
under $GIT_DIR/refs; this can contain paths other than what
git-init-db prepares and would fail to clone when there is
such.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
|
|
