summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2017-03-28Merge branch 'rs/update-hook-optim' into maintLibravatar Junio C Hamano1-8/+5
Code clean-up. * rs/update-hook-optim: receive-pack: simplify run_update_post_hook()
2017-03-28Merge branch 'rs/shortlog-cleanup' into maintLibravatar Junio C Hamano1-1/+0
Code clean-up. * rs/shortlog-cleanup: shortlog: don't set after_subject to an empty string
2017-03-28Merge branch 'jk/pack-name-cleanups' into maintLibravatar Junio C Hamano1-16/+15
Code clean-up. * jk/pack-name-cleanups: index-pack: make pointer-alias fallbacks safer replace snprintf with odb_pack_name() odb_pack_keep(): stop generating keepfile name sha1_file.c: make pack-name helper globally accessible move odb_* declarations out of git-compat-util.h
2017-03-28Merge branch 'jk/rev-parse-cleanup' into maintLibravatar Junio C Hamano1-52/+57
Code clean-up. * jk/rev-parse-cleanup: rev-parse: simplify parsing of ref options rev-parse: add helper for parsing "--foo/--foo=" rev-parse: use skip_prefix when parsing options
2017-03-28Merge branch 'rs/blame-code-cleanup' into maintLibravatar Junio C Hamano1-17/+8
Code clean-up. * rs/blame-code-cleanup: blame: move blame_entry duplication to add_blame_entry()
2017-03-28Merge branch 'mm/fetch-show-error-message-on-unadvertised-object' into maintLibravatar Junio C Hamano1-6/+1
"git fetch" that requests a commit by object name, when the other side does not allow such an request, failed without much explanation. * mm/fetch-show-error-message-on-unadvertised-object: fetch-pack: add specific error for fetching an unadvertised object fetch_refs_via_pack: call report_unmatched_refs fetch-pack: move code to report unmatched refs to a function
2017-03-28Merge branch 'jk/interpret-branch-name' into maintLibravatar Junio C Hamano3-3/+6
"git branch @" created refs/heads/@ as a branch, and in general the code that handled @{-1} and @{upstream} was a bit too loose in disambiguating. * jk/interpret-branch-name: checkout: restrict @-expansions when finding branch strbuf_check_ref_format(): expand only local branches branch: restrict @-expansions when deleting t3204: test git-branch @-expansion corner cases interpret_branch_name: allow callers to restrict expansions strbuf_branchname: add docstring strbuf_branchname: drop return value interpret_branch_name: move docstring to header file interpret_branch_name(): handle auto-namelen for @{-1}
2017-03-28Merge branch 'jk/delta-chain-limit' into maintLibravatar Junio C Hamano1-23/+110
"git repack --depth=<n>" for a long time busted the specified depth when reusing delta from existing packs. This has been corrected. * jk/delta-chain-limit: pack-objects: convert recursion to iteration in break_delta_chain() pack-objects: enforce --depth limit in reused deltas
2017-03-24Merge branch 'jk/grep-no-index-fix' into maintLibravatar Junio C Hamano1-27/+55
The code to parse the command line "git grep <patterns>... <rev> [[--] <pathspec>...]" has been cleaned up, and a handful of bugs have been fixed (e.g. we used to check "--" if it is a rev). * jk/grep-no-index-fix: grep: treat revs the same for --untracked as for --no-index grep: do not diagnose misspelt revs with --no-index grep: avoid resolving revision names in --no-index case grep: fix "--" rev/pathspec disambiguation grep: re-order rev-parsing loop grep: do not unnecessarily query repo for "--" grep: move thread initialization a little lower
2017-03-24Merge branch 'jk/push-deadlock-regression-fix' into maintLibravatar Junio C Hamano1-1/+4
"git push" had a handful of codepaths that could lead to a deadlock when unexpected error happened, which has been fixed. * jk/push-deadlock-regression-fix: send-pack: report signal death of pack-objects send-pack: read "unpack" status even on pack-objects failure send-pack: improve unpack-status error messages send-pack: use skip_prefix for parsing unpack status send-pack: extract parsing of "unpack" response receive-pack: fix deadlock when we cannot create tmpdir
2017-03-21Merge branch 'jk/show-branch-lift-name-len-limit' into maintLibravatar Junio C Hamano1-29/+13
"git show-branch" expected there were only very short branch names in the repository and used a fixed-length buffer to hold them without checking for overflow. * jk/show-branch-lift-name-len-limit: show-branch: use skip_prefix to drop magic numbers show-branch: store resolved head in heap buffer show-branch: drop head_len variable
2017-03-21Merge branch 'rl/remote-allow-missing-branch-name-merge' into maintLibravatar Junio C Hamano1-1/+3
"git remote rm X", when a branch has remote X configured as the value of its branch.*.remote, tried to remove branch.*.remote and branch.*.merge and failed if either is unset. * rl/remote-allow-missing-branch-name-merge: remote: ignore failure to remove missing branch.<name>.merge
2017-03-21Merge branch 'dt/gc-ignore-old-gc-logs' into maintLibravatar Junio C Hamano1-7/+50
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-03-18shortlog: don't set after_subject to an empty stringLibravatar René Scharfe1-1/+0
The string after_subject is added to a strbuf by pp_title_line() if it's not NULL. Adding an empty string has the same effect as not adding anything, but the latter is easier, so don't bother changing the context member from NULL to "". Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-18receive-pack: simplify run_update_post_hook()Libravatar René Scharfe1-8/+5
Instead of counting the arguments to see if there are any and then building the full command use a single loop and add the hook command just before the first argument. This reduces duplication and overall code size. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16index-pack: make pointer-alias fallbacks saferLibravatar Jeff King1-8/+12
The final() function accepts a NULL value for certain parameters, and falls back to writing into a reusable "name" buffer, and then either: 1. For "keep_name", requiring all uses to do "keep_name ? keep_name : name.buf". This is awkward, and it's easy to accidentally look at the maybe-NULL keep_name. 2. For "final_index_name" and "final_pack_name", aliasing those pointers to the "name" buffer. This is easier to use, but the aliased pointers become invalid after the buffer is reused (this isn't a bug now, but it's a potential pitfall). One way to make this safer would be to introduce an extra pointer to do the aliasing, and have its lifetime match the validity of the "name" buffer. But it's still easy to accidentally use the wrong name (i.e., to use "final_pack_name" instead of the aliased pointer). Instead, let's use three separate buffers that will remain valid through the function. That makes it safe to alias the pointers and use them consistently. The extra allocations shouldn't matter, as this function is not performance sensitive. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16replace snprintf with odb_pack_name()Libravatar Jeff King1-16/+11
In several places we write the name of the pack filename into a fixed-size buffer using snprintf(), but do not check the return value. As a result, a very long object directory could cause us to quietly truncate the pack filename (potentially leading to a corrupted repository, as a newly written packfile could be missing its .pack extension). We can use odb_pack_name() to do this with a strbuf (and shorten the code, as well). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-16odb_pack_keep(): stop generating keepfile nameLibravatar Jeff King1-3/+3
The odb_pack_keep() function generates the name of a .keep file and opens it. This has two problems: 1. It requires a fixed-size buffer to create the filename and doesn't notice when the result is truncated. 2. Of the two callers, one sometimes wants to open a filename it already has, which makes things awkward (it has to do so manually, and skips the leading-directory creation). Instead, let's have odb_pack_keep() just open the file. Generating the name isn't hard, and a future patch will switch callers over to odb_pack_name() anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15rev-parse: simplify parsing of ref optionsLibravatar Jeff King1-29/+16
All of these options do the same thing "--foo" iterates over the "foo" refs, and "--foo=<glob>" does the same with a glob. We can factor this into its own function to avoid repeating ourselves. There are two subtleties to note: - the original called for_each_branch_ref(), etc, in the non-glob case. Now we will call for_each_ref_in("refs/heads/") which is exactly what for_each_branch_ref() did under the hood. - for --glob, we'll call for_each_glob_ref_in() with a NULL "prefix" argument. Which is exactly what for_each_glob_ref() was doing already. So both cases should behave identically, and it seems reasonable to assume that this will remain the same. The functions we are calling now are the more-generic ones, and the ones we are dropping are just convenience wrappers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15rev-parse: add helper for parsing "--foo/--foo="Libravatar Jeff King1-10/+28
We can't just use a bare skip_prefix() for these cases, because we need to match both the "--foo" form and the "--foo=<value>" form (and tell the difference between the two in the caller). We can wrap this in a simple helper which has two obvious callsites, and will gain some more in the next patch. Note that the error output for abbrev-ref changes slightly, as we don't keep our original "arg" pointer. However, the new output should hopefully be more clear: [before] fatal: unknown mode for --abbrev-ref=foo [after] fatal: unknown mode for --abbrev-ref: foo Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-15rev-parse: use skip_prefix when parsing optionsLibravatar Jeff King1-20/+20
Using skip_prefix lets us avoid manually-counted offsets into the argument string. This patch converts the simple and obvious cases. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-11blame: move blame_entry duplication to add_blame_entry()Libravatar René Scharfe1-17/+8
All callers of add_blame_entry() allocate and copy the second argument. Let the function do it for them, reducing code duplication. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-08real_pathdup(): fix callsites that wanted it to die on errorLibravatar Johannes Schindelin1-3/+3
In 4ac9006f832 (real_path: have callers use real_pathdup and strbuf_realpath, 2016-12-12), we changed the xstrdup(real_path()) pattern to use real_pathdup() directly. The problem with this change is that real_path() calls strbuf_realpath() with die_on_error = 1 while real_pathdup() calls it with die_on_error = 0. Meaning that in cases where real_path() causes Git to die() with an error message, real_pathdup() is silent and returns NULL instead. The callers, however, are ill-prepared for that change, as they expect the return value to be non-NULL (and otherwise the function died with an appropriate error message). Fix this by extending real_pathdup()'s signature to accept the die_on_error flag and simply pass it through to strbuf_realpath(), and then adjust all callers after a careful audit whether they would handle NULLs well. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-07receive-pack: fix deadlock when we cannot create tmpdirLibravatar Jeff King1-1/+4
The err_fd descriptor passed to the unpack() function is intended to be handed off to the child index-pack, and our async muxer will read until it gets EOF. However, if we encounter an error before handing off the descriptor, we must manually close(err_fd). Otherwise we will be waiting for our muxer to finish, while the muxer is waiting for EOF on err_fd. We fixed an identical deadlock already in 49ecfa13f (receive-pack: close sideband fd on early pack errors, 2013-04-19). But since then, the function grew a new early-return in 722ff7f87 (receive-pack: quarantine objects until pre-receive accepts, 2016-10-03), when we fail to create a temporary directory. This return needs the same treatment. Reported-by: Horst Schirmeier <horst@schirmeier.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02fetch-pack: move code to report unmatched refs to a functionLibravatar Matt McCutchen1-6/+1
Prepare to reuse this code in transport.c for "git fetch". While we're here, internationalize the existing error message. Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02checkout: restrict @-expansions when finding branchLibravatar Jeff King1-1/+1
When we parse "git checkout $NAME", we try to interpret $NAME as a local branch-name. If it is, then we point HEAD to that branch. Otherwise, we detach the HEAD at whatever commit $NAME points to. We do the interpretation by calling strbuf_branchname(), and then blindly sticking "refs/heads/" on the front. This leads to nonsense results when expansions like "@{upstream}" or "@" point to something besides a local branch. We end up with a local branch name like "refs/heads/origin/master" or "refs/heads/HEAD". Normally this has no user-visible effect because those branches don't exist, and so we fallback to feeding the result to get_sha1(), which resolves them correctly. But as the new test in t3204 shows, there are corner cases where the effect is observable, and we check out the wrong local branch rather than detaching to the correct one. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02branch: restrict @-expansions when deletingLibravatar Jeff King1-1/+4
We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We can fix this by passing the appropriate "allowed" flag to strbuf_branchname(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02interpret_branch_name: allow callers to restrict expansionsLibravatar Jeff King3-3/+3
The interpret_branch_name() function converts names like @{-1} and @{upstream} into branch names. The expanded ref names are not fully qualified, and may be outside of the refs/heads/ namespace (e.g., "@" expands to "HEAD", and "@{upstream}" is likely to be in "refs/remotes/"). This is OK for callers like dwim_ref() which are primarily interested in resolving the resulting name, no matter where it is. But callers like "git branch" treat the result as a branch name in refs/heads/. When we expand to a ref outside that namespace, the results are very confusing (e.g., "git branch @" tries to create refs/heads/HEAD, which is nonsense). Callers can't know from the returned string how the expansion happened (e.g., did the user really ask for a branch named "HEAD", or did we do a bogus expansion?). One fix would be to return some out-parameters describing the types of expansion that occurred. This has the benefit that the caller can generate precise error messages ("I understood @{upstream} to mean origin/master, but that is a remote tracking branch, so you cannot create it as a local name"). However, out-parameters make the function interface somewhat cumbersome. Instead, let's do the opposite: let the caller tell us which elements to expand. That's easier to pass in, and none of the callers give more precise error messages than "@{upstream} isn't a valid branch name" anyway (which should be sufficient). The strbuf_branchname() function needs a similar parameter, as most of the callers access interpret_branch_name() through it. We can break the callers down into two groups: 1. Callers that are happy with any kind of ref in the result. We pass "0" here, so they continue to work without restrictions. This includes merge_name(), the reflog handling in add_pending_object_with_path(), and substitute_branch_name(). This last is what powers dwim_ref(). 2. Callers that have funny corner cases (mostly in git-branch and git-checkout). These need to make use of the new parameter, but I've left them as "0" in this patch, and will address them individually in follow-on patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-21remote: ignore failure to remove missing branch.<name>.mergeLibravatar Ross Lagerwall1-1/+3
It is not all too unusual for a branch to use "branch.<name>.remote" without "branch.<name>.merge". You may be using the 'push.default' configuration set to 'current', for example, and do $ git checkout -b side colleague/side $ git config branch.side.remote colleague However, "git remote rm" to remove the remote used in such a manner fails with "fatal: could not unset 'branch.<name>.merge'" because it assumes that a branch that has .remote defined must also have .merge defined. Detect the "cannot unset because it is not set to begin with" case and ignore it. Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-16Merge branch 'rs/strbuf-cleanup-in-rmdir-recursively'Libravatar Junio C Hamano1-3/+3
Code clean-up. * rs/strbuf-cleanup-in-rmdir-recursively: rm: reuse strbuf for all remove_dir_recursively() calls, again
2017-02-16Merge branch 'rs/ls-files-partial-optim'Libravatar Junio C Hamano1-10/+11
"ls-files" run with pathspec has been micro-optimized to avoid having to memmove(3) unnecessary bytes. * rs/ls-files-partial-optim: ls-files: move only kept cache entries in prune_cache() ls-files: pass prefix length explicitly to prune_cache()
2017-02-15show-branch: use skip_prefix to drop magic numbersLibravatar Jeff King1-11/+8
We make several starts_with() calls, only to advance pointers. This is exactly what skip_prefix() is for, which lets us avoid manually-counted magic numbers. Helped-by: Pranit Bauva <pranit.bauva@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-15Merge branch 'rs/swap'Libravatar Junio C Hamano2-9/+4
Code clean-up. * rs/swap: graph: use SWAP macro diff: use SWAP macro use SWAP macro apply: use SWAP macro add SWAP macro
2017-02-14grep: treat revs the same for --untracked as for --no-indexLibravatar Jeff King1-5/+5
git-grep has always disallowed grepping in a tree (as opposed to the working directory) with both --untracked and --no-index. But we traditionally did so by first collecting the revs, and then complaining when any were provided. The --no-index option recently learned to detect revs much earlier. This has two user-visible effects: - we don't bother to resolve revision names at all. So when there's a rev/path ambiguity, we always choose to treat it as a path. - likewise, when you do specify a revision without "--", the error you get is "no such path" and not "--untracked cannot be used with revs". The rationale for doing this with --no-index is that it is meant to be used outside a repository, and so parsing revs at all does not make sense. This patch gives --untracked the same treatment. While it _is_ meant to be used in a repository, it is explicitly about grepping the non-repository contents. Telling the user "we found a rev, but you are not allowed to use revs" is not really helpful compared to "we treated your argument as a path, and could not find it". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14show-branch: store resolved head in heap bufferLibravatar Jeff King1-14/+5
We resolve HEAD and copy the result to a fixed-size buffer with memcpy, never checking that it actually fits. This bug dates back to 8098a178b (Add git-symbolic-ref, 2005-09-30). Before that we used readlink(), which took a maximum buffer size. We can fix this by using resolve_refdup(), which duplicates the buffer on the heap. That also lets us just check for a NULL pointer to see if we have resolved HEAD, and drop the extra head_p variable. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14show-branch: drop head_len variableLibravatar Jeff King1-6/+2
We copy the result of resolving HEAD into a buffer and keep track of its length. But we never actually use the length for anything besides the copy. Let's stop passing it around. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: do not diagnose misspelt revs with --no-indexLibravatar Jeff King1-1/+1
If we are using --no-index, then our arguments cannot be revs in the first place. Not only is it pointless to diagnose them, but if we are not in a repository, we should not be trying to resolve any names. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: avoid resolving revision names in --no-index caseLibravatar Jeff King1-0/+6
We disallow the use of revisions with --no-index, but we don't actually check and complain until well after we've parsed the revisions. This is the cause of a few problems: 1. We shouldn't be calling get_sha1() at all when we aren't in a repository, as it might access the ref or object databases. For now, this should generally just return failure, but eventually it will become a BUG(). 2. When there's a "--" disambiguator and you're outside a repository, we'll complain early with "unable to resolve revision". But we can give a much more specific error. 3. When there isn't a "--" disambiguator, we still do the normal rev/path checks. This is silly, as we know we cannot have any revs with --no-index. Everything we see must be a path. Outside of a repository this doesn't matter (since we know it won't resolve), but inside one, we may complain unnecessarily if a filename happens to also match a refname. This patch skips the get_sha1() call entirely in the no-index case, and behaves as if it failed (with the exception of giving a better error message). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: fix "--" rev/pathspec disambiguationLibravatar Jeff King1-5/+24
If we see "git grep pattern rev -- file" then we apply the usual rev/pathspec disambiguation rules: any "rev" before the "--" must be a revision, and we do not need to apply the verify_non_filename() check. But there are two bugs here: 1. We keep a seen_dashdash flag to handle this case, but we set it in the same left-to-right pass over the arguments in which we parse "rev". So when we see "rev", we do not yet know that there is a "--", and we mistakenly complain if there is a matching file. We can fix this by making a preliminary pass over the arguments to find the "--", and only then checking the rev arguments. 2. If we can't resolve "rev" but there isn't a dashdash, that's OK. We treat it like a path, and complain later if it doesn't exist. But if there _is_ a dashdash, then we know it must be a rev, and should treat it as such, complaining if it does not resolve. The current code instead ignores it and tries to treat it like a path. This patch fixes both bugs, and tries to comment the parsing flow a bit better. It adds tests that cover the two bugs, but also some related situations (which already worked, but this confirms that our fixes did not break anything). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: re-order rev-parsing loopLibravatar Jeff King1-9/+11
We loop over the arguments, but every branch of the loop hits either a "continue" or a "break". Surely we can make this simpler. The final conditional is: if (arg is a rev) { ... handle rev ... continue; } break; We can rewrite this as: if (arg is not a rev) break; ... handle rev ... That makes the flow a little bit simpler, and will make things much easier to follow when we add more logic in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: do not unnecessarily query repo for "--"Libravatar Jonathan Tan1-4/+5
When running a command of the form git grep --no-index pattern -- path in the absence of a Git repository, an error message will be printed: fatal: BUG: setup_git_env called without repository This is because "git grep" tries to interpret "--" as a rev. "git grep" has always tried to first interpret "--" as a rev for at least a few years, but this issue was upgraded from a pessimization to a bug in commit 59332d1 ("Resurrect "git grep --no-index"", 2010-02-06), which calls get_sha1 regardless of whether --no-index was specified. This bug appeared to be benign until commit b1ef400 ("setup_git_env: avoid blind fall-back to ".git"", 2016-10-20) when Git was taught to die in this situation. (This "git grep" bug appears to be one of the bugs that commit b1ef400 is meant to flush out.) Therefore, always interpret "--" as signaling the end of options, instead of trying to interpret it as a rev first. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-14grep: move thread initialization a little lowerLibravatar Jeff King1-14/+14
Originally, we set up the threads for grep before parsing the non-option arguments. In 53b8d931b (grep: disable threading in non-worktree case, 2011-12-12), the thread code got bumped lower in the function because it now needed to know whether we got any revision arguments. That put a big block of code in between the parsing of revs and the parsing of pathspecs, both of which share some loop variables. That makes it harder to read the code than the original, where the shared loops were right next to each other. Let's bump the thread initialization until after all of the parsing is done. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-13gc: ignore old gc.log filesLibravatar David Turner1-7/+50
A server can end up in a state where there are lots of unreferenced loose objects (say, because many users are doing a bunch of rebasing and pushing their rebased branches). Running "git gc --auto" in this state would cause a gc.log file to be created, preventing future auto gcs, causing pack files to pile up. Since many git operations are O(n) in the number of pack files, this would lead to poor performance. Git should never get itself into a state where it refuses to do any maintenance, just because at some point some piece of the maintenance didn't make progress. Teach Git to ignore gc.log files which are older than (by default) one day old, which can be tweaked via the gc.logExpiry configuration variable. That way, these pack files will get cleaned up, if necessary, at least once per day. And operators who find a need for more-frequent gcs can adjust gc.logExpiry to meet their needs. There is also some cleanup: a successful manual gc, or a warning-free auto gc with an old log file, will remove any old gc.log files. It might still happen that manual intervention is required (e.g. because the repo is corrupt), but at the very least it won't be because Git is too dumb to try again. Signed-off-by: David Turner <dturner@twosigma.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-13rm: reuse strbuf for all remove_dir_recursively() calls, againLibravatar René Scharfe1-3/+3
Don't throw the memory allocated for remove_dir_recursively() away after a single call, use it for the other entries as well instead. This change was done before in deb8e15a (rm: reuse strbuf for all remove_dir_recursively() calls), but was reverted as a side-effect of 55856a35 (rm: absorb a submodules git dir before deletion). Reinstate the optimization. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-13ls-files: move only kept cache entries in prune_cache()Libravatar René Scharfe1-5/+4
prune_cache() first identifies those entries at the start of the sorted array that can be discarded. Then it moves the rest of the entries up. Last it identifies the unwanted trailing entries among the moved ones and cuts them off. Change the order: Identify both start *and* end of the range to keep first and then move only those entries to the top. The resulting code is slightly shorter and a bit more efficient. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-13ls-files: pass prefix length explicitly to prune_cache()Libravatar René Scharfe1-5/+7
The function prune_cache() relies on the fact that it is only called on max_prefix and sneakily uses the matching global variable max_prefix_len directly. Tighten its interface by passing both the string and its length as parameters. While at it move the NULL check into the function to collect all cache-pruning related logic in one place. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10Merge branch 'js/difftool-builtin'Libravatar Junio C Hamano1-4/+4
A few hot-fixes to C-rewrite of "git difftool". * js/difftool-builtin: t7800: simplify basic usage test difftool: fix bug when printing usage
2017-02-10Merge branch 'ps/worktree-prune-help-fix'Libravatar Junio C Hamano1-2/+2
Incorrect usage help message for "git worktree prune" has been fixed. * ps/worktree-prune-help-fix: worktree: fix option descriptions for `prune`
2017-02-06worktree: fix option descriptions for `prune`Libravatar Patrick Steinhardt1-2/+2
The `verbose` and `expire` options of the `git worktree prune` subcommand have wrong descriptions in that they pretend to relate to objects. But as the git-worktree(1) correctly states, these options have nothing to do with objects but only with worktrees. Fix the description accordingly. Signed-off-by: Patrick Steinhardt <patrick.steinhardt@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-06difftool: fix bug when printing usageLibravatar David Aguilar1-4/+4
"git difftool -h" reports an error: fatal: BUG: setup_git_env called without repository Defer repository setup so that the help option processing happens before the repository is initialized. Add tests to ensure that the basic usage works inside and outside of a repository. Signed-off-by: David Aguilar <davvid@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>