summaryrefslogtreecommitdiff
path: root/fetch-pack.c
AgeCommit message (Collapse)AuthorFilesLines
2006-11-03improve fetch-pack's handling of kept packsLibravatar Nicolas Pitre1-7/+103
Since functions in fetch-clone.c were only used from fetch-pack.c, its content has been merged with fetch-pack.c. This allows for better coupling of features with much simpler implementations. One new thing is that the (abscence of) --thin also enforce it on index-pack now, such that index-pack will abort if a thin pack was _not_ asked for. The -k or --keep, when provided twice, now causes the fetched pack to be left as a kept pack just like receive-pack currently does. Eventually this will be used to close a race against concurrent repacking. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-11-03Merge branch 'master' into np/index-packLibravatar Junio C Hamano1-4/+4
* master: (90 commits) gitweb: Better support for non-CSS aware web browsers gitweb: Output also empty patches in "commitdiff" view gitweb: Use git-for-each-ref to generate list of heads and/or tags for-each-ref: "creator" and "creatordate" fields Add --global option to git-repo-config. pack-refs: Store the full name of the ref even when packing only tags. git-clone documentation didn't mention --origin as equivalent of -o Minor grammar fixes for git-diff-index.txt link_temp_to_file: call adjust_shared_perm() only when we created the directory Remove uneccessarily similar printf() from print_ref_list() in builtin-branch pack-objects doesn't create random pack names branch: work in subdirectories. gitweb: Use 's' regexp modifier to secure against filenames with LF gitweb: Secure against commit-ish/tree-ish with the same name as path gitweb: esc_html() author in blame git-svnimport: support for partial imports link_temp_to_file: don't leave the path truncated on adjust_shared_perm failure Move deny_non_fast_forwards handling completely into receive-pack. revision traversal: --unpacked does not limit commit list anymore. Continue traversal when rev-list --unpacked finds a packed commit. ...
2006-11-01Merge branch 'lj/refs'Libravatar Junio C Hamano1-4/+4
* lj/refs: (63 commits) Fix show-ref usagestring t3200: git-branch testsuite update sha1_name.c: avoid compilation warnings. Make git-branch a builtin ref-log: fix D/F conflict coming from deleted refs. git-revert with conflicts to behave as git-merge with conflicts core.logallrefupdates thinko-fix git-pack-refs --all core.logallrefupdates create new log file only for branch heads. Remove bashism from t3210-pack-refs.sh ref-log: allow ref@{count} syntax. pack-refs: call fflush before fsync. pack-refs: use lockfile as everybody else does. git-fetch: do not look into $GIT_DIR/refs to see if a tag exists. lock_ref_sha1_basic does not remove empty directories on BSD Do not create tag leading directories since git update-ref does it. Check that a tag exists using show-ref instead of looking for the ref file. Use git-update-ref to delete a tag instead of rm()ing the ref file. Fix refs.c;:repack_without_ref() clean-up path Clean up "git-branch.sh" and add remove recursive dir test cases. ...
2006-10-27enhance clone and fetch -k experienceLibravatar Nicolas Pitre1-2/+0
Now that index-pack can be streamed with a pack, it is probably a good idea to use it directly instead of creating a temporary file and running index-pack afterwards. This way index-pack can abort early whenever a corruption is encountered even if the pack has not been fully downloaded, it can display a progress percentage as it knows how much to expects, and it is a bit faster since the pack indexing is partially done as data is received. Using fetch -k doesn't need to disable thin pack generation on the remote end either. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-27let the GIT native protocol use offsets to delta base when possibleLibravatar Nicolas Pitre1-2/+3
There is no reason not to always do this when both ends agree. Therefore a client that can accept offsets to delta base always sends the "ofs-delta" flag. The server will stream a pack with or without offset to delta base depending on whether that flag is provided or not with no additional cost. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20Tell between packed, unpacked and symbolic refs.Libravatar Junio C Hamano1-2/+2
This adds a "int *flag" parameter to resolve_ref() and makes for_each_ref() family to call callback function with an extra "int flag" parameter. They are used to give two bits of information (REF_ISSYMREF and REF_ISPACKED) about the ref. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20Add callback data to for_each_ref() family.Libravatar Junio C Hamano1-4/+4
This is a long overdue fix to the API for for_each_ref() family of functions. It allows the callers to specify a callback data pointer, so that the caller does not have to use static variables to communicate with the callback funciton. The updated for_each_ref() family takes a function of type int (*fn)(const char *, const unsigned char *, void *) and a void pointer as parameters, and calls the function with the name of the ref and its SHA-1 with the caller-supplied void pointer as parameters. The commit updates two callers, builtin-name-rev.c and builtin-pack-refs.c as an example. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-17Merge branch 'jc/archive'Libravatar Junio C Hamano1-3/+9
* jc/archive: git-tar-tree: devolve git-tar-tree into a wrapper for git-archive git-archive: inline default_parse_extra() builtin-archive.c: rename remote_request() to extract_remote_arg() upload-archive: monitor child communication more carefully. Add sideband status report to git-archive protocol Prepare larger packet buffer for upload-pack protocol. Teach --exec to git-archive --remote Add --verbose to git-archive archive: force line buffered output to stderr Use xstrdup instead of strdup in builtin-{tar,zip}-tree.c Move sideband server side support into reusable form. Move sideband client side support into reusable form. archive: allow remote to have more formats than we understand. git-archive: make compression level of ZIP archives configurable Add git-upload-archive git-archive: wire up ZIP format. git-archive: wire up TAR format. Add git-archive
2006-09-13Test return value of finish_connect()Libravatar Franck Bui-Huu1-2/+2
Signed-off-by: Franck Bui-Huu <vagabon.xyz@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-10Prepare larger packet buffer for upload-pack protocol.Libravatar Junio C Hamano1-3/+9
The original side-band support added to the upload-pack protocol used the default 1000-byte packet length. The pkt-line format allows up to 64k, so prepare the receiver for the maximum size, and have the uploader and downloader negotiate if larger packet length is allowed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-23Convert memcpy(a,b,20) to hashcpy(a,b).Libravatar Shawn Pearce1-1/+1
This abstracts away the size of the hash values when copying them from memory location to memory location, much as the introduction of hashcmp abstracted away hash value comparsion. A few call sites were using char* rather than unsigned char* so I added the cast rather than open hashcpy to be void*. This is a reasonable tradeoff as most call sites already use unsigned char* and the existing hashcmp is also declared to be unsigned char*. [jc: Splitted the patch to "master" part, to be followed by a patch for merge-recursive.c which is not in "master" yet. Fixed the cast in the latter hunk to combine-diff.c which was wrong in the original. Also converted ones left-over in combine-diff.c, diff-lib.c and upload-pack.c ] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15remove unnecessary initializationsLibravatar David Rientjes1-3/+3
[jc: I needed to hand merge the changes to the updated codebase, so the result needs to be checked.] Signed-off-by: David Rientjes <rientjes@google.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-12Remove TYPE_* constant macros and use object_type enums consistently.Libravatar Linus Torvalds1-5/+5
This updates the type-enumeration constants introduced to reduce the memory footprint of "struct object" to match the type bits already used in the packfile format, by removing the former (i.e. TYPE_* constant macros) and using the latter (i.e. enum object_type) throughout the code for consistency. Eventually we can stop passing around the "type strings" entirely, and this will help - no confusion about two different integer enumeration. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-21upload-pack/fetch-pack: support side-band communicationLibravatar Junio C Hamano1-6/+16
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 <junkio@cox.net>
2006-06-17Shrink "struct object" a bitLibravatar Linus Torvalds1-5/+5
This shrinks "struct object" by a small amount, by getting rid of the "struct type *" pointer and replacing it with a 3-bit bitfield instead. In addition, we merge the bitfields and the "flags" field, which incidentally should also remove a useless 4-byte padding from the object when in 64-bit mode. Now, our "struct object" is still too damn large, but it's now less obviously bloated, and of the remaining fields, only the "util" (which is not used by most things) is clearly something that should be eventually discarded. This shrinks the "git-rev-list --all" memory use by about 2.5% on the kernel archive (and, perhaps more importantly, on the larger mozilla archive). That may not sound like much, but I suspect it's more on a 64-bit platform. There are other remaining inefficiencies (the parent lists, for example, probably have horrible malloc overhead), but this was pretty obvious. Most of the patch is just changing the comparison of the "type" pointer from one of the constant string pointers to the appropriate new TYPE_xxx small integer constant. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-24fetch-pack: give up after getting too many "ack continue"Libravatar Junio C Hamano1-0/+16
If your repository have more roots than the remote repository you ask an object for, the remote upload-pack keeps responding "ack continue" until it fills up its received-have buffer (currently 256 entries). Usually this is not a problem because the requester stops traversing the ancestry chain from the commit it gets "ack continue" for, but this mechanism does not work as a roadblock when it traverses down the path to the root the other side does not have. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-22fetch-pack: output refs in the order they were given on the command line.Libravatar Junio C Hamano1-15/+51
Currently, fetched refs are output in the order the remote side happened to send them. This changes the order to match the order of refs that were given on the command line. To the existing core callers (git-fetch and git-clone) this does not make any difference, but for other Porcelain use, it would be more intuitive. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20revamp git-clone.Libravatar Junio C Hamano1-4/+14
This does two things. * A new flag --reference can be used to name a local repository that is to be used as an alternate. This is in response to an inquiry by James Cloos in the message on the list <m3r74ykue7.fsf@lugabout.cloos.reno.nv.us>. * A new flag --use-separate-remote stops contaminating local branch namespace by upstream branch names. The upstream branch heads are copied in .git/refs/remotes/ instead of .git/refs/heads/ and .git/remotes/origin file is set up to reflect this as well. It requires to have fetch/pull update to understand .git/refs/remotes by Eric Wong to further update the repository cloned this way. For the former change, git-fetch-pack is taught a new flag --all to fetch from all the remote heads. Nobody uses the git-clone-pack with this change, so we could deprecate the command, but removal of the command will be left to a separate round. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-26Use setenv(), fix warningsLibravatar Timo Hirvonen1-1/+1
- Fix -Wundef -Wold-style-definition warnings - Make pll_free() static [jc: original patch by Timo had another unrelated bits: - Use setenv() instead of putenv() I'm postponing that part for now.] Signed-off-by: Timo Hirvonen <tihirvon@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-20Use thin pack transfer in "git fetch".Libravatar Junio C Hamano1-4/+11
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-10Make "git clone" less of a deathly quiet experienceLibravatar Linus Torvalds1-1/+1
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>
2006-01-19git-fetch-pack: really do not ask for funny refsLibravatar Johannes Schindelin1-3/+0
If git-fetch-pack was called with out any refspec, it would ask the server for funny refs. That cannot work, since the funny refs are not marked as OUR_REF by upload-pack, which just exits with an error. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-18clone-pack: remove unused and undocumented --keep flagLibravatar Junio C Hamano1-2/+2
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>
2005-12-17fetch-pack: -k option to keep downloaded pack.Libravatar Junio C Hamano1-37/+21
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>
2005-11-28Make networking commands to work from a subdirectory.Libravatar Junio C Hamano1-0/+2
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>
2005-11-06git-fetch: fail if specified refspec does not match remote.Libravatar Junio C Hamano1-0/+14
'git-fetch remote no-such-ref' succeeded without fetching any ref from the remote. Detect such case and report an error. Note that this makes 'git-fetch remote master master' to fail, because the remote branch 'master' matches the first refspec, and the second refspec is left unmatched, which is detected by the error checking logic. This is somewhat unintuitive, but giving the same refspec more than once to git-fetch is useless in any case so it should not be much of a problem. I'd accept a patch to change this if somebody cares enough, though. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-02Be careful when dereferencing tags.Libravatar Junio C Hamano1-3/+4
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 <junkio@cox.net>
2005-10-28git-fetch-pack: Support multi_ack extensionLibravatar Johannes Schindelin1-16/+42
The client side support for multi_ack. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28Make maximal use of the remote refsLibravatar Johannes Schindelin1-20/+52
When git-fetch-pack gets the remote refs, it does not need to filter them right away, but it can see which refs are common (taking advantage of the patch which makes git-fetch-pack not use git-rev-list). This means that we ask get_remote_heads() to return all remote refs, including the funny refs, and filtering them with a separate function later. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-28Subject: [PATCH] git-fetch-pack: Do not use git-rev-listLibravatar Johannes Schindelin1-32/+132
The code used to call git-rev-list to enumerate the local revisions. A disadvantage of that method was that git-rev-list, lacking a control apart from the command line, would happily enumerate ancestors of acknowledged common commits, which was just taking unnecessary bandwidth. Therefore, do not use git-rev-list on the fetching side, but rather construct the list on the go. Send the revisions starting from the local heads, ignoring the revisions known to be common. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-25Revert recent fetch-pack/upload-pack updates.Libravatar Junio C Hamano1-155/+44
Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-24git-fetch-pack: Implement client part of the multi_ack extensionLibravatar Johannes Schindelin1-13/+37
This patch concludes the series, which makes git-fetch-pack/git-upload-pack negotiate a potentially better set of common revs. It should make a difference when fetching from a repository with a few branches. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-24git-fetch-pack: Do not use git-rev-listLibravatar Johannes Schindelin1-32/+119
The code used to call git-rev-list to enumerate the local revisions. A disadvantage of that method was that git-rev-list, lacking a control apart from the command line, would happily enumerate ancestors of acknowledged common commits, which was just taking unnecessary bandwidth. Therefore, do not use git-rev-list on the fetching side, but rather construct the list on the go. Send the revisions starting from the local heads, ignoring the revisions known to be common. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Be more careful tangling object chains while marking commits.Libravatar Junio C Hamano1-4/+10
Also Johannes noticed we use parse_object to look up if we know that object already -- we should just ask the in-core object registry with lookup_object() for that. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Do not feed rev-list an invalid SHA1 expression.Libravatar Junio C Hamano1-9/+23
The previous round to optimize fetch-pack has a small bug that feeds SHA1^ ("parent commit") before making sure SHA1 is actually a commit (or a tag that eventually dereferences to a commit). Also it did not help culling the known-to-be-common parents if the common one was a merge. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19[PATCH] Do not send "want" lines for complete objectsLibravatar Johannes Schindelin1-8/+25
It was all good and well to check if all remote refs are complete (local refs or descendants thereof), but we can just as easily use the same information to avoid sending "want" lines just for the complete objects in the case that not all remote refs are complete (or their names differ). Also, git-fetch-pack does not have to ask for descendants of remote refs which are complete (for now, git-rev-list is told to ignore only the first parent). That change also eliminates a code path where a popen()ed handle was not pclose()ed. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-19Do not ask for objects known to be complete.Libravatar Junio C Hamano1-2/+62
On top of optimization by Linus not to ask refs that already match, we can walk our refs and not issue "want" for things that are known to be reachable from them. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-18git-fetch-pack: avoid unnecessary zero packingLibravatar Linus Torvalds1-6/+44
If everything is up-to-date locally, we don't need to even ask for a pack-file from the remote, or try to unpack it. This is especially important for tags - since the pack-file common commit logic is based purely on the commit history, it will never be able to find a common tag, and will thus always end up re-fetching them. Especially notably, if the tag points to a non-commit (eg a tagged tree), the pack-file would be unnecessarily big, just because it cannot any most recent common point between commits for pruning. Short-circuiting the case where we already have that reference means that we avoid a lot of these in the common case. NOTE! This only matches remote ref names against the same local name, which works well for tags, but is not as generic as it could be. If we ever need to, we could match against _any_ local ref (if we have it, we have it), but this "match against same name" is simpler and more efficient, and covers the common case. Renaming of refs is common for branch heads, but since those are always commits, the pack-file generation can optimize that case. In some cases we might still end up fetching pack-files unnecessarily, but this at least avoids the re-fetching of tags over and over if you use a regular git fetch --tags ... which was the main reason behind the change. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-15Ignore funny refname sent from remoteLibravatar Junio C Hamano1-1/+1
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>
2005-08-12fetch-pack: start multi-head pulling.Libravatar Junio C Hamano1-16/+40
This is a beginning of resurrecting the multi-head pulling support for git-fetch-pack command. The git-fetch-script wrapper still only knows about fetching a single head, without renaming, so it is not very useful unless you directly call git-fetch-pack itself yet. It also fixes a longstanding obsolete description of how the command discovers the list of local commits.
2005-07-16Merge three separate "fetch refs" functionsLibravatar Linus Torvalds1-33/+17
It really just boils down to one "get_remote_heads()" function, and a common "struct ref" structure definition.
2005-07-14[PATCH] Documentation: clone/fetch/upload.Libravatar Junio C Hamano1-3/+8
This adds documentation for 'smarter pull' family of commands. Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-07-13Get rid of nasty utf-8 characters in printoutLibravatar Linus Torvalds1-1/+1
Oh, well.. FC4 has UTF-8 as the default environment, and I applaud that, but then it sometimes results in these characters that aren't actually visible as a problem.
2005-07-13git-fetch-pack: close output fd after dup'ing the inputLibravatar Linus Torvalds1-1/+1
With the socket case, the input and output fd's might end up being the same, so we want to dup the other before we close either of them.
2005-07-05Move "get_ack()" to common git_connect functionsLibravatar Linus Torvalds1-18/+0
git-clone-pack will want it too. Soon.
2005-07-05Remove multi-head support from fetch-packLibravatar Linus Torvalds1-38/+3
It was a misguided attempt to mix fetching and cloning. I'll make a separate clone thing.
2005-07-05Add "git_path()" and "head_ref()" helper functions.Libravatar Linus Torvalds1-5/+1
"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.Libravatar Linus Torvalds1-14/+48
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 fullyLibravatar Linus Torvalds1-9/+62
Now the only piece missing is actually generating the pack-file.
2005-07-04Commit first cut at "git-fetch-pack"Libravatar Linus Torvalds1-0/+125
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.