path: root/upload-pack.c
AgeCommit message (Collapse)Author
2006-03-05Const tightening.Junio C Hamano
Mark Wooding noticed there was a type mismatch warning in git.c; this patch does things slightly differently (mostly tightening const) and was what I was holding onto, waiting for the setup-revisions change to be merged into the master branch. Signed-off-by: Junio C Hamano <>
2006-02-25Merge branches 'jc/rev-list' and 'jc/pack-thin'Junio C Hamano
* jc/rev-list: rev-list --objects: use full pathname to help hashing. rev-list --objects-edge: remove duplicated edge commit output. rev-list --objects-edge * jc/pack-thin: pack-objects: hash basename and direname a bit differently. pack-objects: allow "thin" packs to exceed depth limits pack-objects: use full pathname to help hashing with "thin" pack. pack-objects: thin pack micro-optimization. Use thin pack transfer in "git fetch". Add git-push --thin. send-pack --thin: use "thin pack" delta transfer. Thin pack - create packfile with missing delta base. Conflicts: pack-objects.c (taking "next") send-pack.c (taking "next")
2006-02-20Use thin pack transfer in "git fetch".Junio C Hamano
Signed-off-by: Junio C Hamano <>
2006-02-18Prevent git-upload-pack segfault if object cannot be foundCarl Worth
Signed-off-by: Carl Worth <> 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 <>
2005-11-20Server-side support for user-relative paths.Andreas Ericsson
This patch basically just removes the redundant code from {receive,upload}-pack.c in favour of the library code in path.c. Signed-off-by: Andreas Ericsson <> Signed-off-by: Junio C Hamano <>
2005-11-03Be careful when dereferencing tags.Junio C Hamano
One caller of deref_tag() was not careful enough to make sure what deref_tag() returned was not NULL (i.e. we found a tag object that points at an object we do not have). Fix it, and warn about refs that point at such an incomplete tag where needed. Signed-off-by: Junio C Hamano <>
2005-10-29fix multi_ack.Johannes Schindelin
Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-29git-upload-pack: Support the multi_ack protocolJohannes Schindelin
This implements three things (trying very hard to be backwards compatible): It sends the "multi_ack" capability via the mechanism proposed by Sergey Vlasov. When the client sends "multi_ack" with at least one "want", multi_ack is enabled. When multi_ack is enabled, "continue" is appended to each "ACK" until either the server can not store more refs, or "done" is received. In contrast to the original protocol, as long as "continue" is sent, flushes are answered by a "NAK" (not just until an "ACK" was sent), and if "continue" was sent at least once, the last message is an "ACK" without "continue". Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-29git-upload-pack: More efficient usage of the has_sha1 arrayJohannes Schindelin
This patch is based on Junio's proposal. It marks parents of common revs so that they do not clutter up the has_sha1 array. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-26Fix cloning (memory corruption)Johannes Schindelin
upload-pack would set create_full_pack=1 if nr_has==0, but would ask later if nr_needs<MAX_NEEDS. If that proves true, it would ignore create_full_pack, and arguments would be written into unreserved memory. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-26upload-pack: tighten request validation.Junio C Hamano
This makes sure what the other end asks for are among what we offered to give them. Otherwise we would end up running git-rev-list with 20-byte nonsense, only to find it either die (because the object was not found) or waste time (because we ended up serving that phony 'client'). Also avoid wasting needs_sha1 pool to record duplicates, and detect cloning requests better. [this used to be on top of Johannes fetch-pack enhancements, which we are rewinding it for further testing for now, so the commit is rebased.] Signed-off-by: Junio C Hamano <>
2005-10-25Revert recent fetch-pack/upload-pack updates.Junio C Hamano
Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano <>
2005-10-24upload-pack: fix thinko in common-commit finder code.Junio C Hamano
The code to check if we have the object the other side has was bogus (my fault). Signed-off-by: Junio C Hamano <>
2005-10-24git-upload-pack: Support sending multiple ACK messagesJohannes Schindelin
The current fetch/upload protocol works like this: - client sends revs it wants to have via "want" messages - client sends a flush message (message with len 0) - client sends revs it has via "have" messages - after one window (32 revs), a flush is sent - after each subsequent window, a flush is sent, and an ACK/NAK is received. (NAK means that server does not have any of the transmitted revs; ACK sends also the sha1 of the rev server has) - when the first ACK is received, client sends "done", and does not expect any further messages One special case, though: - if no ACK is received (only NAK's), and client runs out of revs to send, "done" is sent, and server sends just one more "NAK" A smarter scheme, which actually has a chance to detect more than one common rev, would be to send more than just one ACK. This patch implements the server side of the following extension to the protocol: - client sends at least one "want" message with "multi_ack" appended, like "want 1234567890123456789012345678901234567890 multi_ack" - if the server understands that extension, it will send ACK messages for all revs it has, not just the first one - server appends "continue" to the ACK messages like "ACK 1234567890123456789012345678901234567890 continue" until it has MAX_HAS-1 revs. In this manner, client knows when to stop sending revs by checking for the substring "continue" (and further knows that server understands multi_ack) In this manner, the protocol stays backwards compatible, since both client must send "want ... multi_ack" and server must answer with "ACK ... continue" to enable the extension. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-24git-upload-pack: More efficient usage of the has_sha1 arrayJohannes Schindelin
This patch is based on Junio's proposal. It marks parents of common revs so that they do not clutter up the has_sha1 array. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2005-10-22upload-pack: Increase MAX_HAS.Junio C Hamano
Later round would further improve fetch-pack not to send useless "have", but in the meantime, increase it to help upload-pack to find more common commits, as discussed on the list. Signed-off-by: Junio C Hamano <>
2005-10-19git-daemon: timeout, eliminate double DWIMH. Peter Anvin
It turns out that not only did git-daemon do DWIM, but git-upload-pack does as well. This is bad; security checks have to be performed *after* canonicalization, not before. Additionally, the current git-daemon can be trivially DoSed by spewing SYNs at the target port. This patch adds a --strict option to git-upload-pack to disable all DWIM, a --timeout option to git-daemon and git-upload-pack, and an --init-timeout option to git-daemon (which is typically set to a much lower value, since the initial request should come immediately from the client.) Signed-off-by: H. Peter Anvin <> Signed-off-by: Junio C Hamano <>
2005-10-15Show peeled onion from upload-pack and server-info.Junio C Hamano
This updates git-ls-remote to show SHA1 names of objects that are referred by tags, in the "ref^{}" notation. This would make git-findtags (without -t flag) almost trivial. git-peek-remote . | sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p' Also Pasky could do: git-ls-remote --tags $remote | sed -ne 's:\( refs/tags/.*\)^{}$:\1:p' to find out what object each of the remote tags refers to, and if he has one locally, run "git-fetch $remote tag $tagname" to automatically catch up with the upstream tags. Signed-off-by: Junio C Hamano <>
2005-10-05upload-pack: Do not choke on too many heads request.Junio C Hamano
Cloning from a repository with more than 256 refs (heads and tags included) will choke, because upload-pack has a built-in limit of feeding not more than MAX_NEEDS (currently 256) heads to underlying git-rev-list. This is a problem when cloning a repository with many tags, like, which has 290+ tags. This commit introduces a new flag, --all, to git-rev-list, to include all refs in the repository. Updated upload-pack detects requests that ask more than MAX_NEEDS refs, and sends everything back instead. We may probably want to tweak the definitions of MAX_NEEDS and MAX_HAS, but that is a separate topic. Signed-off-by: Junio C Hamano <>
2005-08-24Replace unsetenv() and setenv() with older putenv().Jason Riedy
Solaris 8 doesn't have the newer unsetenv() and setenv() functions, so replace them with putenv(). The one use of unsetenv() in fsck-cache.c now sets GIT_ALTERNATE_OBJECT_ DIRECTORIES to the empty string. Every place that var is used, NULLs are also replaced with empty strings, so it's ok. Signed-off-by: Jason Riedy <>
2005-07-08Make "upload-pack" match git-fetch-pack usageLinus Torvalds
Do the default "try xyz.git xyz fails" thing for the directory we get passed in.
2005-07-06Increase the number of possible heads requested from git-upload-packLinus Torvalds
Now that git-clone-pack exists, we actually have somebody requesting more than just a single head in a pack. So allow the Jeff's of this world to clone things with tens of heads.
2005-07-05Add "git_path()" and "head_ref()" helper functions.Linus Torvalds
"git_path()" returns a static pathname pointer into the git directory using a printf-like format specifier. "head_ref()" works like "for_each_ref()", except for just the HEAD.
2005-07-04Make git-fetch-pack actually do all the unpacking etc.Linus Torvalds
It returns the result SHA1 on stdout, so you can do remote=$(git-fetch-pack host:dir branchname) and it will unpack the objects and "remote" will be the SHA1 name of the branch on the other side. You can then save that off, or merge it, or whatever.
2005-07-04Make git-fetch-pack and git-upload-pack negotiate needs/haves fullyLinus Torvalds
Now the only piece missing is actually generating the pack-file.
2005-07-04Commit first cut at "git-fetch-pack"Linus Torvalds
It's meant to be used by "git fetch" for the local and ssh case. It doesn't actually do the fetching now, but it does discover the common commit point.