aboutsummaryrefslogtreecommitdiffstats
path: root/tools/lib/find_bit.c
diff options
context:
space:
mode:
Diffstat (limited to 'tools/lib/find_bit.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-20 09:08:48 +0000
061e272079229d1ab2799d8e7a4f65213f&follow=1'>thin-pack: try harder to use preferred base objects as baseJeff King1-2/+7 When creating a pack using objects that reside in existing packs, we try to avoid recomputing futile delta between an object (trg) and a candidate for its base object (src) if they are stored in the same packfile, and trg is not recorded as a delta already. This heuristics makes sense because it is likely that we tried to express trg as a delta based on src but it did not produce a good delta when we created the existing pack. As the pack heuristics prefer producing delta to remove data, and Linus's law dictates that the size of a file grows over time, we tend to record the newest version of the file as inflated, and older ones as delta against it. When creating a thin-pack to transfer recent history, it is likely that we will try to send an object that is recorded in full, as it is newer. But the heuristics to avoid recomputing futile delta effectively forbids us from attempting to express such an object as a delta based on another object. Sending an object in full is often more expensive than sending a suboptimal delta based on other objects, and it is even more so if we could use an object we know the receiving end already has (i.e. preferred base object) as the delta base. Tweak the recomputation avoidance logic, so that we do not punt on computing delta against a preferred base object. The effect of this change can be seen on two simulated upload-pack workloads. The first is based on 44 reflog entries from my git.git origin/master reflog, and represents the packs that kernel.org sent me git updates for the past month or two. The second workload represents much larger fetches, going from git's v1.0.0 tag to v1.1.0, then v1.1.0 to v1.2.0, and so on. The table below shows the average generated pack size and the average CPU time consumed for each dataset, both before and after the patch: dataset | reflog | tags --------------------------------- before | 53358 | 2750977 size after | 32398 | 2668479 change | -39% | -3% --------------------------------- before | 0.18 | 1.12 CPU after | 0.18 | 1.15 change | +0% | +3% This patch makes a much bigger difference for packs with a shorter slice of history (since its effect is seen at the boundaries of the pack) though it has some benefit even for larger packs. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11archive: re-allow HEAD:Documentation on a remote invocationCarlos Martín Nieto1-6/+15 The tightening done in (ee27ca4a: archive: don't let remote clients get unreachable commits, 2011-11-17) went too far and disallowed HEAD:Documentation as it would try to find "HEAD:Documentation" as a ref. Only DWIM the "HEAD" part to see if it exists as a ref. Once we're sure that we've been given a valid ref, we follow the normal code path. This still disallows attempts to access commits which are not branch tips. Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11attr: fix leak in free_attr_elemJeff King1-0/+1 This function frees the individual "struct match_attr"s we have allocated, but forgot to free the array holding their pointers, leading to a minor memory leak (but it can add up after checking attributes for paths in many directories). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11git-cvsexportcommit: Fix calling Perl's rel2abs() on MSYSSebastian Schuberth1-0/+7 Due to MSYS path mangling GIT_DIR contains a Windows-style path when checked inside a Perl script even if GIT_DIR was previously set to an MSYS-style path in a shell script. So explicitly convert to an MSYS-style path before calling Perl's rel2abs() to make it work. This fix was inspired by a very similar patch in WebKit: http://trac.webkit.org/changeset/76255/trunk/Tools/Scripts/commit-log-editor Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Tested-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11t9200: On MSYS, do not pass Windows-style paths to CVSSebastian Schuberth1-3/+3 For details, see the commit message of 4114156ae9. Note that while using $PWD as part of GIT_DIR is not required here, it does no harm and it is more consistent. In addition, on MSYS using an environment variable should be slightly faster than spawning an external executable. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11mailinfo documentation: accurately describe non -k caseThomas Rast1-7/+18 Since its very first description of -k, the documentation for git-mailinfo claimed that (in the case without -k) after cleaning up bracketed strings [blah], it would insert [PATCH]. It doesn't; on the contrary, one of the important jobs of mailinfo is to remove those strings. Since we're already there, rewrite the paragraph to give a complete enumeration of all the transformations. Specifically, it was missing the whitespace normalization (run of isspace(c) -> ' ') and the removal of leading ':'. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-11t2203: fix wrong commit commandNguyễn Thái Ngọc Duy1-1/+1 Add commit message to avoid commit's aborting due to the lack of commit message, not because there are INTENT_TO_ADD entries in index. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10Prepare for 1.7.8.4Junio C Hamano2-1/+15 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10Prepare for 1.7.7.6Junio C Hamano2-1/+12 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10Prepare for 1.7.6.6Junio C Hamano2-1/+12 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10Documentation: rerere's rr-cache auto-creation and rerere.enabledJunio C Hamano1-1/+2 The description of rerere.enabled left the user in the dark as to who might create an rr-cache directory. Add a note that simply invoking rerere does this. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10attr.c: clarify the logic to pop attr_stackJunio C Hamano1-1/+10 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10attr.c: make bootstrap_attr_stack() leave earlyJunio C Hamano1-30/+31 Thas would de-dent the body of a function that has grown rather large over time, making it a bit easier to read. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10attr: drop misguided defensive codingJeff King1-1/+1 In prepare_attr_stack, we pop the old elements of the stack (which were left from a previous lookup and may or may not be useful to us). Our loop to do so checks that we never reach the top of the stack. However, the code immediately afterwards will segfault if we did actually reach the top of the stack. Fortunately, this is not an actual bug, since we will never pop all of the stack elements (we will always keep the root gitattributes, as well as the builtin ones). So the extra check in the loop condition simply clutters the code and makes the intent less clear. Let's get rid of it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-10attr: don't confuse prefixes with leading directoriesJeff King2-1/+12 When we prepare the attribute stack for a lookup on a path, we start with the cached stack from the previous lookup (because it is common to do several lookups in the same directory hierarchy). So the first thing we must do in preparing the stack is to pop any entries that point to directories we are no longer interested in. For example, if our stack contains gitattributes for: foo/bar/baz foo/bar foo but we want to do a lookup in "foo/bar/bleep", then we want to pop the top element, but retain the others. To do this we walk down the stack from the top, popping elements that do not match our lookup directory. However, the test do this simply checked strncmp, meaning we would mistake "foo/bar/baz" as a leading directory of "foo/bar/baz_plus". We must also check that the character after our match is '/', meaning we matched the whole path component. There are two special cases to consider: 1. The top of our attr stack has the empty path. So we must not check for '/', but rather special-case the empty path, which always matches. 2. Typically when matching paths in this way, you would also need to check for a full string match (i.e., the character after is '\0'). We don't need to do so in this case, though, because our path string is actually just the directory component of the path to a file (i.e., we know that it terminates with "/", because the filename comes after that). Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-09Use perl instead of sed for t8006-blame-textconv testBen Walton1-1/+1 In test 'blame --textconv with local changes' of t8006-blame-textconv, using /usr/xpg4/bin/sed (as set by SANE_TOOL_PATH), an additional newline was added to the output from the 'helper' script. This was noted by sed with a message such as: sed: Missing newline at end of file zero.bin. Sed then exits with status 2 causing the helper script to also exit with status 2. In turn, this was triggering a fatal error from git blame: fatal: unable to read files to diff To work around this difference in sed behaviour, use perl -p instead of sed -e as it exits cleanly and does not insert the additional newline. Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-09send-email: multiedit is a boolean config optionJeff King1-1/+1 The sendemail.multiedit variable is meant to be a boolean. However, it is not marked as such in the code, which means we store its value literally. Thus in the do_edit function, perl ends up coercing it to a boolean value according to perl rules, not git rules. This works for "0", but "false", "no", or "off" will erroneously be interpreted as true. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-08credentials: unable to connect to cache daemonClemens Buchacher1-4/+3 Error out if we just spawned the daemon and yet we cannot connect. And always release the string buffer. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06Git 1.7.9-rc0v1.7.9-rc0Junio C Hamano2-1/+8 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06Git 1.7.8.3v1.7.8.3Junio C Hamano4-3/+22 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06Documentation: rerere.enabled is the primary way to configure rerereThomas Rast1-4/+4 The wording seems to suggest that creating the directory is needed and the setting of rerere.enabled is only for disabling the feature by setting it to 'false'. But the configuration is meant to be the primary control and setting it to 'true' will enable it; the rr-cache directory will be created as necessary and the user does not have to create it. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06write_head_info(): handle "extra refs" locallyMichael Haggerty1-4/+3 The old code basically did: generate array of SHA1s for alternate refs for each unique SHA1 in array: add_extra_ref(".have", sha1) for each ref (including real refs and extra refs): show_ref(refname, sha1) But there is no need to stuff the alternate refs in extra_refs; we can call show_ref() directly when iterating over the array, then handle real refs separately. So change the code to: generate array of SHA1s for alternate refs for each unique SHA1 in array: show_ref(".have", sha1) for each ref (this now only includes real refs): show_ref(refname, sha1) Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06show_ref(): remove unused "flag" and "cb_data" argumentsMichael Haggerty1-5/+5 The function is not used as a callback, so it doesn't need these arguments. Also change its return type to void. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-06receive-pack: move more work into write_head_info()Michael Haggerty1-24/+18 Move some more code from the calling site into write_head_info(), and inline add_alternate_refs() there. (Some more simplification is coming, and it is easier if all this code is in the same place.) Move some helper functions to avoid the need for forward declarations. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-05log --show-signature: reword the common two-head merge caseJunio C Hamano1-0/+12 While identifying the commit merged to our history as "parent #2" is technically correct, we will never say "parent #1" (as that is the tip of our history before the merge is made), and we rarely would say "parent #3" (which would mean the merge is an octopus), especially when responding to a request to pull a signed tag. Treat the most common case to merge a single commit specially, and just say "merged tag '<tagname>'" instead. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-05log-tree: show mergetag in log --show-signature outputJunio C Hamano1-1/+75 A commit object that merges a signed tag records the "mergetag" extended header. Check the validity of the GPG signature on it, and show it in a way similar to how "gpgsig" extended header is shown. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-05log-tree.c: small refactor in show_signature()Junio C Hamano1-12/+16 The next patch needs to show the result of signature verification on a mergetag extended header in a way similar to how embedded signature for the commit object itself is shown. Separate out the logic to go through the message lines and show them in the "error" color (highlighted) or the "correct" color (dim). Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-05commit --amend -S: strip existing gpgsig headersJunio C Hamano4-8/+36 Any existing commit signature was made against the contents of the old commit, including its committer date that is about to change, and will become invalid by amending it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-05verify_signed_buffer: fix stale commentJunio C Hamano1-4/+1 The function used to take an integer flag to specify where the output should go, but these days we supply a strbuf to receive it. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-04t5550: repack everything into one fileClemens Buchacher1-2/+1 Subsequently we assume that there is only one pack. Currently this is true only by accident. Pass '-a -d' to repack in order to guarantee that assumption to hold true. The prune-packed command is now redundant since repack -d already calls it. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-04gitweb: accept trailing "/" in $project_listMatthieu Moy1-2/+2 The current code is removing the trailing "/", but computing the string length on the previous value, i.e. with the trailing "/". Later in the code, we do my $path = substr($File::Find::name, $pfxlen + 1); And the "$pfxlen + 1" is supposed to mean "the length of the prefix, plus 1 for the / separating the prefix and the path", but with an incorrect $pfxlen, this basically eats the first character of the path, and yields "404 - No projects found". While we're there, also fix $pfxdepth to use $dir, although a change of 1 in the depth shouldn't really matter. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-04Catch invalid --depth option passed to clone or fetchNguyễn Thái Ngọc Duy1-2/+6 Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03write first for-merge ref to FETCH_HEAD firstJoey Hess25-102/+114 The FETCH_HEAD refname is supposed to refer to the ref that was fetched and should be merged. However all fetched refs are written to .git/FETCH_HEAD in an arbitrary order, and resolve_ref_unsafe simply takes the first ref as the FETCH_HEAD, which is often the wrong one, when other branches were also fetched. The solution is to write the for-merge ref(s) to FETCH_HEAD first. Then, unless --append is used, the FETCH_HEAD refname behaves as intended. If the user uses --append, they presumably are doing so in order to preserve the old FETCH_HEAD. While we are at it, update an old example in the read-tree documentation that implied that each entry in FETCH_HEAD only has the object name, which is not true for quite a while. [jc: adjusted tests] Signed-off-by: Joey Hess <joey@kitenet.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03git-p4: view spec documentationPete Wyckoff1-13/+27 Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03git-p4: rewrite view handlingPete Wyckoff2-101/+258 The old code was not very complete or robust. Redo it. This new code should be useful for a few possible additions in the future: - support for * and %%n wildcards - allowing ... inside paths - representing branch specs (not just client specs) - tracking changes to views Mark the remaining 12 tests in t9809 as fixed. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03git-p4: support single file p4 client view mapsGary Gibbons2-10/+21 Perforce client views can map individual files, mapping one //depot file path to one //client file path. These mappings contain no meta/masking characters. This patch add support for these file maps to the currently supported '...' view mappings. [pw: one test now suceeds] Signed-off-by: Gary Gibbons <ggibbons@perforce.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03git-p4: sort client views by reverse View numberGary Gibbons2-3/+10 Correct view sorting to support the Perforce order, where client views are ordered and later views override earlier view mappings. [pw: one test now succeeds] Signed-off-by: Gary Gibbons <ggibbons@perforce.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2012-01-03git-p4: fix test for unsupported P4 Client ViewsGary Gibbons2-3/+6 Change re method in test for unsupported Client View types (containing %% or *) anywhere in the string rather than at the begining. [pw: two tests now succeed] Signed-off-by: Gary Gibbons <ggibbons@perforce.com> Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>