summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-03-16upload-pack: drop lookup-before-parse optimizationLibravatar Jeff King1-3/+1
When we receive a "have" line from the client, we want to load the object pointed to by the sha1. However, we are careful to do: o = lookup_object(sha1); if (!o || !o->parsed) o = parse_object(sha1); to avoid loading the object from disk if we have already seen it. However, since ccdc603 (parse_object: try internal cache before reading object db), parse_object already does this optimization internally. We can just call parse_object directly. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04upload-pack: use peel_ref for ref advertisementsLibravatar Jeff King1-11/+3
When upload-pack advertises refs, we attempt to peel tags and advertise the peeled version. We currently hand-roll the tag dereferencing, and use as many optimizations as we can to avoid loading non-tag objects into memory. Not only has peel_ref recently learned these optimizations, too, but it also contains an even more important one: it has access to the "peeled" data from the pack-refs file. That means we can avoid not only loading annotated tags entirely, but also avoid doing any kind of object lookup at all. This cut the CPU time to advertise refs by 50% in the linux-2.6 repo, as measured by: echo 0000 | git-upload-pack . >/dev/null best-of-five, warm cache, objects and refs fully packed: [before] [after] real 0m0.026s real 0m0.013s user 0m0.024s user 0m0.008s sys 0m0.000s sys 0m0.000s Those numbers are irrelevantly small compared to an actual fetch. Here's a larger repo (400K refs, of which 12K are unique, and of which only 107 are unique annotated tags): [before] [after] real 0m0.704s real 0m0.596s user 0m0.600s user 0m0.496s sys 0m0.096s sys 0m0.092s This shows only a 15% speedup (mostly because it has fewer actual tags to parse), but a larger absolute value (100ms, which isn't a lot compared to a real fetch, but this advertisement happens on every fetch, even if the client is just finding out they are completely up to date). In truly pathological cases, where you have a large number of unique annotated tags, it can make an even bigger difference. Here are the numbers for a linux-2.6 repository that has had every seventh commit tagged (so about 50K tags): [before] [after] real 0m0.443s real 0m0.097s user 0m0.416s user 0m0.080s sys 0m0.024s sys 0m0.012s Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04peel_ref: check object type before loadingLibravatar Jeff King1-2/+9
The point of peel_ref is to dereference tags; if the base object is not a tag, then we can return early without even loading the object into memory. This patch accomplishes that by checking sha1_object_info for the type. For a packed object, we can get away with just looking in the pack index. For a loose object, we only need to inflate the first couple of header bytes. This is a bit of a gamble; if we do find a tag object, then we will end up loading the content anyway, and the extra lookup will have been wasteful. However, if it is not a tag object, then we save loading the object entirely. Depending on the ratio of non-tags to tags in the input, this can be a minor win or minor loss. However, it does give us one potential major win: if a ref points to a large blob (e.g., via an unannotated tag), then we can avoid looking at it entirely. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04peel_ref: do not return a null sha1Libravatar Jeff King4-22/+6
The idea of the peel_ref function is to dereference tag objects recursively until we hit a non-tag, and return the sha1. Conceptually, it should return 0 if it is successful (and fill in the sha1), or -1 if there was nothing to peel. However, the current behavior is much more confusing. For a regular loose ref, the behavior is as described above. But there is an optimization to reuse the peeled-ref value for a ref that came from a packed-refs file. If we have such a ref, we return its peeled value, even if that peeled value is null (indicating that we know the ref definitely does _not_ peel). It might seem like such information is useful to the caller, who would then know not to bother loading and trying to peel the object. Except that they should not bother loading and trying to peel the object _anyway_, because that fallback is already handled by peel_ref. In other words, the whole point of calling this function is that it handles those details internally, and you either get a sha1, or you know that it is not peel-able. This patch catches the null sha1 case internally and converts it into a -1 return value (i.e., there is nothing to peel). This simplifies callers, which do not need to bother checking themselves. Two callers are worth noting: - in pack-objects, a comment indicates that there is a difference between non-peelable tags and unannotated tags. But that is not the case (before or after this patch). Whether you get a null sha1 has to do with internal details of how peel_ref operated. - in show-ref, if peel_ref returns a failure, the caller tries to decide whether to try peeling manually based on whether the REF_ISPACKED flag is set. But this doesn't make any sense. If the flag is set, that does not necessarily mean the ref came from a packed-refs file with the "peeled" extension. But it doesn't matter, because even if it didn't, there's no point in trying to peel it ourselves, as peel_ref would already have done so. In other words, the fallback peeling is guaranteed to fail. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-04peel_ref: use faster deref_tag_noverifyLibravatar Jeff King1-1/+1
When we are asked to peel a ref to a sha1, we internally call deref_tag, which will recursively parse each tagged object until we reach a non-tag. This has the benefit that we will verify our ability to load and parse the pointed-to object. However, there is a performance downside: we may not need to load that object at all (e.g., if we are listing peeled simply listing peeled refs), or it may be a large object that should follow a streaming code path (e.g., an annotated tag of a large blob). It makes more sense for peel_ref to choose the fast thing rather than performing the extra check, for two reasons: 1. We will already sometimes short-circuit the tag parsing in favor of a peeled entry from a packed-refs file. So we are already favoring speed in some cases, and it is not wise for a caller to rely on peel_ref to detect corruption. 2. We already silently ignore much larger corruptions, like a ref that points to a non-existent object, or a tag object that exists but is corrupted. 2. peel_ref is not the right place to check for such a database corruption. It is returning only the sha1 anyway, not the actual object. Any callers which use that sha1 to load an object will soon discover the corruption anyway, so we are really just pushing back the discovery to later in the program. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-02Start preparing for 1.7.12.3Libravatar Junio C Hamano2-1/+19
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-02Merge branch 'rr/maint-submodule-unknown-cmd' into maintLibravatar Junio C Hamano3-4/+11
"git submodule frotz" was not diagnosed as "frotz" being an unknown subcommand to "git submodule"; the user instead got a complaint that "git submodule status" was run with an unknown path "frotz". * rr/maint-submodule-unknown-cmd: submodule: if $command was not matched, don't parse other args
2012-10-02Merge branch 'sp/maint-http-enable-gzip' into maintLibravatar Junio C Hamano3-3/+5
"git fetch" over http advertised that it supports "deflate", which is much less common, and did not advertise more common "gzip" on its Accept-Encoding header. * sp/maint-http-enable-gzip: Enable info/refs gzip decompression in HTTP client
2012-10-02Merge branch 'sp/maint-http-info-refs-no-retry' into maintLibravatar Junio C Hamano1-16/+2
"git fetch" over http had an old workaround for an unlikely server misconfiguration; it turns out that this hurts debuggability of the configuration in general, and has been reverted. * sp/maint-http-info-refs-no-retry: Revert "retry request without query when info/refs?query fails"
2012-10-02l10n: Fix to Swedish translationLibravatar Peter Krefting1-2/+2
Fix bad translation of "Receiving objects". Signed-off-by: Peter Krefting <peter@softwolves.pp.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Git 1.7.12.2Libravatar Junio C Hamano3-2/+11
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-29Merge branch 'maint' of git://github.com/git-l10n/git-po into maintLibravatar Junio C Hamano2-28/+28
Update German and Simplified Chinese translations. * 'maint' of git://github.com/git-l10n/git-po: l10n: de.po: correct translation of a 'rebase' message l10n: Improve many translation for zh_CN l10n: Unify the translation for '(un)expected'
2012-09-29Merge branch 'jc/maint-log-grep-all-match-1' into maintLibravatar Junio C Hamano6-25/+217
* jc/maint-log-grep-all-match-1: grep.c: make two symbols really file-scope static this time t7810-grep: test --all-match with multiple --grep and --author options t7810-grep: test interaction of multiple --grep and --author options t7810-grep: test multiple --author with --all-match t7810-grep: test multiple --grep with and without --all-match t7810-grep: bring log --grep tests in common form grep.c: mark private file-scope symbols as static log: document use of multiple commit limiting options log --grep/--author: honor --all-match honored for multiple --grep patterns grep: show --debug output only once grep: teach --debug option to dump the parse tree
2012-09-29Merge branch 'jc/maint-mailinfo-mime-attr' into maintLibravatar Junio C Hamano6-4/+32
* jc/maint-mailinfo-mime-attr: mailinfo: do not concatenate charset= attribute values from mime headers
2012-09-28Merge branch 'l10n-thynson' of git://github.com/thynson/git-po-zh_CN into maintLibravatar Jiang Xin1-23/+23
* 'l10n-thynson' of git://github.com/thynson/git-po-zh_CN: l10n: Improve many translation for zh_CN l10n: Unify the translation for '(un)expected'
2012-09-28Merge branch 'maint' of https://github.com/ralfth/git-po-de into maintLibravatar Jiang Xin1-5/+5
* 'maint' of https://github.com/ralfth/git-po-de: l10n: de.po: correct translation of a 'rebase' message
2012-09-27l10n: de.po: correct translation of a 'rebase' messageLibravatar Ralf Thielow1-5/+5
Noticed-by: Sascha Cunz <sascha-ml@babbelbox.org> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
2012-09-25submodule: if $command was not matched, don't parse other argsLibravatar Ramkumar Ramachandra3-4/+11
"git submodule" command DWIMs the command line and assumes a unspecified action word for 'status' action. This is a UI mistake that leads to a confusing behaviour. A mistyped command name is instead treated as a request for 'status' of the submodule with that name, e.g. $ git submodule show error: pathspec 'show' did not match any file(s) known to git. Did you forget to 'git add'? Stop DWIMming an unknown or mistyped subcommand name as pathspec given to unspelled "status" subcommand. "git submodule" without any argument is still interpreted as "git submodule status", but its value is questionable. Adjust t7400 to match, and stop advertising the default subcommand being 'status' which does not help much in practice, other than promoting laziness and confusion. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-25Revert "completion: fix shell expansion of items"Libravatar Jeff King1-8/+1
This reverts commit 25ae7cfd19c8f21721363c64163cd5d9d1135b20. That patch does fix expansion of weird variables in some simple tests, but it also seems to break other things, like expansion of refs by "git checkout". While we're sorting out the correct solution, we are much better with the original bug (people with metacharacters in their completions occasionally see an error message) than the current bug (ref completion does not work at all). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24Start preparation for 1.7.12.2Libravatar Junio C Hamano2-1/+33
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-24Merge branch 'jc/maint-blame-no-such-path' into maintLibravatar Junio C Hamano2-17/+74
Even during a conflicted merge, "git blame $path" always meant to blame uncommitted changes to the "working tree" version; make it more useful by showing cleanly merged parts as coming from the other branch that is being merged. This incidentally fixes an unrelated problem on a case insensitive filesystem, where "git blame MAKEFILE" run in a history that has "Makefile" but not "MAKEFILE" did not say "No such file MAKEFILE in HEAD" but pretended as if "MAKEFILE" was a newly added file. * jc/maint-blame-no-such-path: blame: allow "blame file" in the middle of a conflicted merge blame $path: avoid getting fooled by case insensitive filesystems
2012-09-24Merge branch 'dj/fetch-all-tags' into maintLibravatar Junio C Hamano7-39/+92
"git fetch --all", when passed "--no-tags", did not honor the "--no-tags" option while fetching from individual remotes (the same issue existed with "--tags", but combination "--all --tags" makes much less sense than "--all --no-tags"). * dj/fetch-all-tags: fetch --all: pass --tags/--no-tags through to each remote submodule: use argv_array instead of hand-building arrays fetch: use argv_array instead of hand-building arrays argv-array: fix bogus cast when freeing array argv-array: add pop function
2012-09-24Improve the description of GIT_PS1_SHOWUPSTREAMLibravatar Jonathan "Duke" Leto1-3/+4
Describe what '=' means in the output of __git_ps1 when using GIT_PS1_SHOWUPSTREAM, which was not previously described. Signed-off-by: Jonathan "Duke" Leto <jonathan@leto.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Merge branch 'nd/maint-diffstat-summary' into maintLibravatar Junio C Hamano1-6/+4
* nd/maint-diffstat-summary: Revert diffstat back to English
2012-09-20Merge branch 'jw/doc-commit-title' into maintLibravatar Junio C Hamano7-22/+31
* jw/doc-commit-title: Documentation: describe subject more precisely
2012-09-20Merge branch 'dg/run-command-child-cleanup' into maintLibravatar Junio C Hamano1-6/+7
* dg/run-command-child-cleanup: run-command.c: fix broken list iteration in clear_child_for_cleanup
2012-09-20Merge branch 'jc/mailinfo-RE' into maintLibravatar Junio C Hamano1-1/+3
* jc/mailinfo-RE: mailinfo: strip "RE: " prefix
2012-09-20Merge branch 'sn/ls-remote-get-url-doc' into maintLibravatar Junio C Hamano2-1/+6
* sn/ls-remote-get-url-doc: ls-remote: document the '--get-url' option
2012-09-20Merge branch 'nd/log-n-doc' into maintLibravatar Junio C Hamano2-5/+4
* nd/log-n-doc: doc: move rev-list option -<n> from git-log.txt to rev-list-options.txt
2012-09-20Merge branch 'nd/maint-remote-remove' into maintLibravatar Junio C Hamano5-9/+10
* nd/maint-remote-remove: remote: prefer subcommand name 'remove' to 'rm'
2012-09-20grep.c: make two symbols really file-scope static this timeLibravatar Junio C Hamano1-2/+2
Adding a declaration at the beginning is not sufficient for obvious reasons. The definition has to be made static. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Documentation: Document signature showing optionsLibravatar Stephen Boyd2-0/+7
The pretty formats for GPG signatures were introduced but never documented. Use the documentation from the commit that introduced them. Do the same for the --show-signature option added to git log and friends. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Enable info/refs gzip decompression in HTTP clientLibravatar Shawn O. Pearce3-3/+5
Some HTTP servers try to use gzip compression on the /info/refs request to save transfer bandwidth. Repositories with many tags may find the /info/refs request can be gzipped to be 50% of the original size due to the few but often repeated bytes used (hex SHA-1 and commonly digits in tag names). For most HTTP requests enable "Accept-Encoding: gzip" ensuring the /info/refs payload can use this encoding format. Only request gzip encoding from servers. Although deflate is supported by libcurl, most servers have standardized on gzip encoding for compression as that is what most browsers support. Asking for deflate increases request sizes by a few bytes, but is unlikely to ever be used by a server. Disable the Accept-Encoding header on probe RPCs as response bodies are supposed to be exactly 4 bytes long, "0000". The HTTP headers requesting and indicating compression use more space than the data transferred in the body. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20Revert "retry request without query when info/refs?query fails"Libravatar Shawn O. Pearce1-16/+2
This reverts commit 703e6e76a14825e5b0c960d525f34e607154b4f7. Retrying without the query parameter was added as a workaround for a single broken HTTP server at git.debian.org[1]. The server was misconfigured to route every request with a query parameter into gitweb.cgi. Admins fixed the server's configuration within 16 hours of the bug report to the Git mailing list, but we still patched Git with this fallback and have been paying for it since. Most Git hosting services configure the smart HTTP protocol and the retry logic confuses users when there is a transient HTTP error as Git dropped the real error from the smart HTTP request. Removing the retry makes root causes easier to identify. [1] http://thread.gmane.org/gmane.comp.version-control.git/137609 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-20completion: fix shell expansion of itemsLibravatar Felipe Contreras1-1/+8
As reported by Jeroen Meijer[1]; the current code doesn't deal properly with items (tags, branches, etc.) that have ${} in them because they get expaned by bash while using compgen. A simple solution is to quote the items so they get expanded properly (\$\{\}). In order to achieve that I took bash-completion's quote() function, which is rather simple, and renamed it to __git_quote() as per Jeff King's suggestion. Solves the original problem for me. [1] http://article.gmane.org/gmane.comp.version-control.git/201596 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Git 1.7.12.1Libravatar Junio C Hamano3-2/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Merge branch 'er/doc-fast-import-done' into maintLibravatar Junio C Hamano1-1/+7
* er/doc-fast-import-done: fast-import: document the --done option
2012-09-18Merge branch 'jk/config-warn-on-inaccessible-paths' into maintLibravatar Junio C Hamano6-10/+34
The attribute system may be asked for a path that itself or its leading directories no longer exists in the working tree, and it is fine if we cannot open .gitattribute file in such a case. Failure to open per-directory .gitattributes with error status other than ENOENT and ENOTDIR should be diagnosed. * jk/config-warn-on-inaccessible-paths: attr: failure to open a .gitattributes file is OK with ENOTDIR warn_on_inaccessible(): a helper to warn on inaccessible paths attr: warn on inaccessible attribute files gitignore: report access errors of exclude files config: warn on inaccessible files
2012-09-18Doc: Improve shallow depth wordingLibravatar Philip Oakley1-2/+4
Avoid confusion in compound sentence about the start of the commit set and the depth measure. Use two sentences. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-18Documentation/git-filter-branch: Move note about effect of removing commitsLibravatar Andreas Schwab1-10/+9
The note that explains that changes introduced by removed commits are preserved should be placed directly after the paragraph that describes such commits removal. Otherwise the reference to "the commits" appears out of context. Also the big example that follows "Consider this history" is about rewriting part of the history DAG. Move the paragraph that describes the operation close to it. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17mailinfo: do not concatenate charset= attribute values from mime headersLibravatar Junio C Hamano6-4/+32
"Content-type: text/plain; charset=UTF-8" header should not appear twice in the input, but it is always better to gracefully deal with such a case. The current code concatenates the value to the values we have seen previously, producing nonsense such as "utf8UTF-8". Instead of concatenating, forget the previous value and use the last value we see. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17t/perf: add "trash directory" to .gitignoreLibravatar Ramkumar Ramachandra1-2/+3
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17Add missing -z to git check-attr usage text for consistency with man pageLibravatar Adam Spiers1-1/+1
Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17git-jump: ignore (custom) prefix in diff modeLibravatar Mischa POSLAWSKY1-2/+2
Matching the default file prefix b/ does not yield any results if config option diff.noprefix or diff.mnemonicprefix is enabled. Signed-off-by: Mischa POSLAWSKY <git@shiar.nl> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17Documentation: indent-with-non-tab uses "equivalent tabs" not 8Libravatar Wesley J. Landaker1-2/+3
Update the documentation of the core.whitespace option "indent-with-non-tab" to correctly reflect that it catches the use of spaces instead of the equivalent tabs, rather than a fixed number. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-16completion: add --no-edit to git-commitLibravatar Yacine Belkadi1-1/+2
Signed-off-by: Yacine Belkadi <yacine.belkadi.1@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test --all-match with multiple --grep and --author optionsLibravatar Michael J Gruber1-0/+20
The code used to have a bug that ignores "--all-match", that requires all "--grep" to have matched, when "--author" or "--committer" was used. Make sure the bug will not be reintroduced. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test interaction of multiple --grep and --author optionsLibravatar Michael J Gruber1-16/+22
There are tests for this interaction already. Restructure slightly and avoid any claims about --all-match. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test multiple --author with --all-matchLibravatar Michael J Gruber1-0/+8
The "--all-match" option is about "--grep", and does not affect how "--author" or "--committer" limitation is applied. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-15t7810-grep: test multiple --grep with and without --all-matchLibravatar Michael J Gruber1-0/+16
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>