git/builtin, branch v2.10.2

Merge branch 'rs/cocci' into maint

2016-10-28T16:01:23Z

Code cleanup. * rs/cocci: use strbuf_add_unique_abbrev() for adding short hashes, part 3 remove unnecessary NULL check before free(3) coccicheck: make transformation for strbuf_addf(sb, "...") more precise use strbuf_add_unique_abbrev() for adding short hashes, part 2 use strbuf_addstr() instead of strbuf_addf() with "%s", part 2 gitignore: ignore output files of coccicheck make target use strbuf_addstr() for adding constant strings to a strbuf, part 2 add coccicheck make target contrib/coccinelle: fix semantic patch for oid_to_hex_r()

Merge branch 'js/reset-usage' into maint

2016-10-28T16:01:22Z

Message fix-up. * js/reset-usage: reset: fix usage

Merge branch 'jk/fetch-quick-tag-following' into maint

2016-10-28T16:01:17Z

When fetching from a remote that has many tags that are irrelevant to branches we are following, we used to waste way too many cycles when checking if the object pointed at by a tag (that we are not going to fetch!) exists in our repository too carefully. * jk/fetch-quick-tag-following: fetch: use "quick" has_sha1_file for tag following

Merge branch 'jk/merge-base-fork-point-without-reflog' into maint

2016-10-28T16:01:17Z

"git rebase" immediately after "git clone" failed to find the fork point from the upstream. * jk/merge-base-fork-point-without-reflog: merge-base: handle --fork-point without reflog

Merge branch 'jk/clone-copy-alternates-fix' into maint

2016-10-28T16:01:14Z

"git clone" of a local repository can be done at the filesystem level, but the codepath did not check errors while copying and adjusting the file that lists alternate object stores. * jk/clone-copy-alternates-fix: clone: detect errors in normalize_path_copy

fetch: use "quick" has_sha1_file for tag following

2016-10-14T18:31:32Z

When we auto-follow tags in a fetch, we look at all of the tags advertised by the remote and fetch ones where we don't already have the tag, but we do have the object it peels to. This involves a lot of calls to has_sha1_file(), some of which we can reasonably expect to fail. Since 45e8a74 (has_sha1_file: re-check pack directory before giving up, 2013-08-30), this may cause many calls to reprepare_packed_git(), which is potentially expensive. This has gone unnoticed for several years because it requires a fairly unique setup to matter: 1. You need to have a lot of packs on the client side to make reprepare_packed_git() expensive (the most expensive part is finding duplicates in an unsorted list, which is currently quadratic). 2. You need a large number of tag refs on the server side that are candidates for auto-following (i.e., that the client doesn't have). Each one triggers a re-read of the pack directory. 3. Under normal circumstances, the client would auto-follow those tags and after one large fetch, (2) would no longer be true. But if those tags point to history which is disconnected from what the client otherwise fetches, then it will never auto-follow, and those candidates will impact it on every fetch. So when all three are true, each fetch pays an extra O(nr_tags * nr_packs^2) cost, mostly in string comparisons on the pack names. This was exacerbated by 47bf4b0 (prepare_packed_git_one: refactor duplicate-pack check, 2014-06-30) which uses a slightly more expensive string check, under the assumption that the duplicate check doesn't happen very often (and it shouldn't; the real problem here is how often we are calling reprepare_packed_git()). This patch teaches fetch to use HAS_SHA1_QUICK to sacrifice accuracy for speed, in cases where we might be racy with a simultaneous repack. This is similar to the fix in 0eeb077 (index-pack: avoid excessive re-reading of pack directory, 2015-06-09). As with that case, it's OK for has_sha1_file() occasionally say "no I don't have it" when we do, because the worst case is not a corruption, but simply that we may fail to auto-follow a tag that points to it. Here are results from the included perf script, which sets up a situation similar to the one described above: Test HEAD^ HEAD ---------------------------------------------------------- 5550.4: fetch 11.21(10.42+0.78) 0.08(0.04+0.02) -99.3% Reported-by: Vegard Nossum Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

merge-base: handle --fork-point without reflog

2016-10-12T21:30:16Z

The --fork-point option looks in the reflog to try to find where a derived branch forked from a base branch. However, if the reflog for the base branch is totally empty (as it commonly is right after cloning, which does not write a reflog entry), then our for_each_reflog call will not find any entries, and we will come up with no merge base, even though there may be one with the current tip of the base. We can fix this by just adding the current tip to our list of collected entries. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/worktree-config' into maint

2016-10-11T21:21:17Z

"git worktree", even though it used the default_abbrev setting that ought to be affected by core.abbrev configuration variable, ignored the variable setting. The command has been taught to read the default set of configuration variables to correct this. * jc/worktree-config: worktree: honor configuration variables

Merge branch 'jc/blame-abbrev' into maint

2016-10-11T21:19:52Z

Almost everybody uses DEFAULT_ABBREV to refer to the default setting for the abbreviation, but "git blame" peeked into underlying variable bypassing the macro for no good reason. * jc/blame-abbrev: blame: use DEFAULT_ABBREV macro

Merge branch 'rs/copy-array' into maint

2016-10-11T21:18:32Z

Code cleanup. * rs/copy-array: use COPY_ARRAY add COPY_ARRAY