summaryrefslogtreecommitdiff
path: root/fetch-pack.c
AgeCommit message (Collapse)AuthorFilesLines
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.