- 03 11月, 2005 1 次提交
-
-
由 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: NJunio C Hamano <junkio@cox.net>
-
- 29 10月, 2005 3 次提交
-
-
由 Johannes Schindelin 提交于
The client side support for multi_ack. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 26 10月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
Let's have it simmer a bit longer in the proposed updates branch and shake the problems out. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 25 10月, 2005 2 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 10月, 2005 4 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 19 10月, 2005 2 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
由 Linus Torvalds 提交于
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: NLinus Torvalds <torvalds@osdl.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 10月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 13 8月, 2005 1 次提交
-
-
由 Junio C Hamano 提交于
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.
-
- 17 7月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
It really just boils down to one "get_remote_heads()" function, and a common "struct ref" structure definition.
-
- 14 7月, 2005 3 次提交
-
-
由 Junio C Hamano 提交于
This adds documentation for 'smarter pull' family of commands. Signed-off-by: NJunio C Hamano <junkio@cox.net> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Linus Torvalds 提交于
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.
-
由 Linus Torvalds 提交于
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.
-
- 06 7月, 2005 3 次提交
-
-
由 Linus Torvalds 提交于
git-clone-pack will want it too. Soon.
-
由 Linus Torvalds 提交于
It was a misguided attempt to mix fetching and cloning. I'll make a separate clone thing.
-
由 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.
-
- 05 7月, 2005 3 次提交
-
-
由 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.
-
由 Linus Torvalds 提交于
Now the only piece missing is actually generating the pack-file.
-
由 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.
-