summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2017-02-27Merge branch 'rl/remote-allow-missing-branch-name-merge'Libravatar 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-02-27Merge branch 'km/delete-ref-reflog-message'Libravatar Junio C Hamano9-14/+15
"git update-ref -d" and other operations to delete references did not leave any entry in HEAD's reflog when the reference being deleted was the current branch. This is not a problem in practice because you do not want to delete the branch you are currently on, but caused renaming of the current branch to something else not to be logged in a useful way. * km/delete-ref-reflog-message: branch: record creation of renamed branch in HEAD's log rename_ref: replace empty message in HEAD's log update-ref: pass reflog message to delete_ref() delete_ref: accept a reflog message argument
2017-02-27Merge branch 'js/git-path-in-subdir'Libravatar Junio C Hamano1-4/+11
The "--git-path", "--git-common-dir", and "--shared-index-path" options of "git rev-parse" did not produce usable output. They are now updated to show the path to the correct file, relative to where the caller is. * js/git-path-in-subdir: rev-parse: fix several options when running in a subdirectory rev-parse tests: add tests executed from a subdirectory
2017-02-27Merge branch 'nd/clean-preserve-errno-in-warning'Libravatar Junio C Hamano1-4/+12
Some warning() messages from "git clean" were updated to show the errno from failed system calls. * nd/clean-preserve-errno-in-warning: clean: use warning_errno() when appropriate
2017-02-27Merge branch 'jk/show-branch-lift-name-len-limit'Libravatar 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-02-27Merge branch 'jk/grep-no-index-fix'Libravatar 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-02-27Merge branch 'dt/gc-ignore-old-gc-logs'Libravatar 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-02-27Merge branch 'js/rebase-helper'Libravatar Junio C Hamano1-0/+40
"git rebase -i" starts using the recently updated "sequencer" code. * js/rebase-helper: rebase -i: use the rebase--helper builtin rebase--helper: add a builtin helper for interactive rebases
2017-02-27Merge branch 'bw/attr'Libravatar Junio C Hamano2-46/+39
The gitattributes machinery is being taught to work better in a multi-threaded environment. * bw/attr: (27 commits) attr: reformat git_attr_set_direction() function attr: push the bare repo check into read_attr() attr: store attribute stack in attr_check structure attr: tighten const correctness with git_attr and match_attr attr: remove maybe-real, maybe-macro from git_attr attr: eliminate global check_all_attr array attr: use hashmap for attribute dictionary attr: change validity check for attribute names to use positive logic attr: pass struct attr_check to collect_some_attrs attr: retire git_check_attrs() API attr: convert git_check_attrs() callers to use the new API attr: convert git_all_attrs() to use "struct attr_check" attr: (re)introduce git_check_attr() and struct attr_check attr: rename function and struct related to checking attributes attr.c: outline the future plans by heavily commenting Documentation: fix a typo attr.c: add push_stack() helper attr: support quoting pathname patterns in C style attr.c: plug small leak in parse_attr_line() attr.c: tighten constness around "git_attr" structure ...
2017-02-27Merge branch 'sg/completion'Libravatar Junio C Hamano1-8/+18
Clean-up and updates to command line completion (in contrib/). * sg/completion: (22 commits) completion: restore removed line continuating backslash completion: cache the path to the repository completion: extract repository discovery from __gitdir() completion: don't guard git executions with __gitdir() completion: consolidate silencing errors from git commands completion: don't use __gitdir() for git commands completion: respect 'git -C <path>' rev-parse: add '--absolute-git-dir' option completion: fix completion after 'git -C <path>' completion: don't offer commands when 'git --opt' needs an argument completion: list short refs from a remote given as a URL completion: don't list 'HEAD' when trying refs completion outside of a repo completion: list refs from remote when remote's name matches a directory completion: respect 'git --git-dir=<path>' when listing remote refs completion: fix most spots not respecting 'git --git-dir=<path>' completion: ensure that the repository path given on the command line exists completion tests: add tests for the __git_refs() helper function completion tests: check __gitdir()'s output in the error cases completion tests: consolidate getting path of current working directory completion tests: make the $cur variable local to the test helper functions ...
2017-02-27Merge branch 'cw/tag-reflog-message'Libravatar Junio C Hamano1-1/+53
"git tag" did not leave useful message when adding a new entry to reflog; this was left unnoticed for a long time because refs/tags/* doesn't keep reflog by default. * cw/tag-reflog-message: tag: generate useful reflog message
2017-02-27Merge branch 'jk/alternate-ref-optim'Libravatar Junio C Hamano1-19/+22
Optimizes resource usage while enumerating refs from alternate object store, to help receiving end of "push" that hosts a repository with many "forks". * jk/alternate-ref-optim: receive-pack: avoid duplicates between our refs and alternates receive-pack: treat namespace .have lines like alternates receive-pack: fix misleading namespace/.have comment receive-pack: use oidset to de-duplicate .have lines add oidset API fetch-pack: cache results of for_each_alternate_ref for_each_alternate_ref: replace transport code with for-each-ref for_each_alternate_ref: pass name/oid instead of ref struct for_each_alternate_ref: use strbuf for path allocation for_each_alternate_ref: stop trimming trailing slashes for_each_alternate_ref: handle failure from real_pathdup()
2017-02-27Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano2-198/+96
The code to list branches in "git branch" has been consolidated with the more generic ref-filter API. * kn/ref-filter-branch-list: (21 commits) ref-filter: resurrect "strip" as a synonym to "lstrip" branch: implement '--format' option branch: use ref-filter printing APIs branch, tag: use porcelain output ref-filter: allow porcelain to translate messages in the output ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' ref-filter: Do not abruptly die when using the 'lstrip=<N>' option ref-filter: rename the 'strip' option to 'lstrip' ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() ref-filter: introduce refname_atom_parser() ref-filter: introduce refname_atom_parser_internal() ref-filter: make "%(symref)" atom work with the ':short' modifier ref-filter: add support for %(upstream:track,nobracket) ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams ref-filter: introduce format_ref_array_item() ref-filter: move get_head_description() from branch.c ref-filter: modify "%(objectname:short)" to take length ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) ref-filter: include reference to 'used_atom' within 'atom_value' ...
2017-02-27Merge branch 'jk/delta-chain-limit'Libravatar 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-02-27Merge branch 'jk/describe-omit-some-refs'Libravatar Junio C Hamano2-19/+90
"git describe" and "git name-rev" have been taught to take more than one refname patterns to restrict the set of refs to base their naming output on, and also learned to take negative patterns to name refs not to be used for naming via their "--exclude" option. * jk/describe-omit-some-refs: describe: teach describe negative pattern matches describe: teach --match to accept multiple patterns name-rev: add support to exclude refs by pattern match name-rev: extend --refs to accept multiple patterns doc: add documentation for OPT_STRING_LIST
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-20branch: record creation of renamed branch in HEAD's logLibravatar Kyle Meyer1-2/+3
Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20update-ref: pass reflog message to delete_ref()Libravatar Kyle Meyer1-1/+1
Now that delete_ref() accepts a reflog message, pass the user-provided message to delete_ref() rather than silently dropping it. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-20delete_ref: accept a reflog message argumentLibravatar Kyle Meyer9-12/+12
When the current branch is renamed with 'git branch -m/-M' or deleted with 'git update-ref -m<msg> -d', the event is recorded in HEAD's log with an empty message. In preparation for adding a more meaningful message to HEAD's log in these cases, update delete_ref() to take a message argument and pass it along to ref_transaction_delete(). Modify all callers to pass NULL for the new message argument; no change in behavior is intended. Note that this is relevant for HEAD's log but not for the deleted ref's log, which is currently deleted along with the ref. Even if it were not, an entry for the deletion wouldn't be present in the deleted ref's log. files_transaction_commit() writes to the log if REF_NEEDS_COMMIT or REF_LOG_ONLY are set, but lock_ref_for_update() doesn't set REF_NEEDS_COMMIT for the deleted ref because REF_DELETING is set. In contrast, the update for HEAD has REF_LOG_ONLY set by split_head_update(), resulting in the deletion being logged. Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-17rev-parse: fix several options when running in a subdirectoryLibravatar Johannes Schindelin1-4/+11
In addition to making git_path() aware of certain file names that need to be handled differently e.g. when running in worktrees, the commit 557bd833bb (git_path(): be aware of file relocation in $GIT_DIR, 2014-11-30) also snuck in a new option for `git rev-parse`: `--git-path`. On the face of it, there is no obvious bug in that commit's diff: it faithfully calls git_path() on the argument and prints it out, i.e. `git rev-parse --git-path <filename>` has the same precise behavior as calling `git_path("<filename>")` in C. The problem lies deeper, much deeper. In hindsight (which is always unfair), implementing the .git/ directory discovery in `setup_git_directory()` by changing the working directory may have allowed us to avoid passing around a struct that contains information about the current repository, but it bought us many, many problems. In this case, when being called in a subdirectory, `git rev-parse` changes the working directory to the top-level directory before calling `git_path()`. In the new working directory, the result is correct. But in the working directory of the calling script, it is incorrect. Example: when calling `git rev-parse --git-path HEAD` in, say, the Documentation/ subdirectory of Git's own source code, the string `.git/HEAD` is printed. Side note: that bug is hidden when running in a subdirectory of a worktree that was added by the `git worktree` command: in that case, the (correct) absolute path of the `HEAD` file is printed. In the interest of time, this patch does not go the "correct" route to introduce a struct with repository information (and removing global state in the process), instead this patch chooses to detect when the command was called in a subdirectory and forces the result to be an absolute path. While at it, we are also fixing the output of --git-common-dir and --shared-index-path. Lastly, please note that we reuse the same strbuf for all of the relative_path() calls; this avoids frequent allocation (and duplicated code), and it does not risk memory leaks, for two reasons: 1) the cmd_rev_parse() function does not return anywhere between the use of the new strbuf instance and its final release, and 2) git-rev-parse is one of these "one-shot" programs in Git, i.e. it exits after running for a very short time, meaning that all allocated memory is released with the exit() call anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> 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-16clean: use warning_errno() when appropriateLibravatar Nguyễn Thái Ngọc Duy1-4/+12
All these warning() calls are preceded by a system call. Report the actual error to help the user understand why we fail to remove something. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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-09rebase--helper: add a builtin helper for interactive rebasesLibravatar Johannes Schindelin1-0/+40
Git's interactive rebase is still implemented as a shell script, despite its complexity. This implies that it suffers from the portability point of view, from lack of expressibility, and of course also from performance. The latter issue is particularly serious on Windows, where we pay a hefty price for relying so much on POSIX. Unfortunately, being such a huge shell script also means that we missed the train when it would have been relatively easy to port it to C, and instead piled feature upon feature onto that poor script that originally never intended to be more than a slightly pimped cherry-pick in a loop. To open the road toward better performance (in addition to all the other benefits of C over shell scripts), let's just start *somewhere*. The approach taken here is to add a builtin helper that at first intends to take care of the parts of the interactive rebase that are most affected by the performance penalties mentioned above. In particular, after we spent all those efforts on preparing the sequencer to process rebase -i's git-rebase-todo scripts, we implement the `git rebase -i --continue` functionality as a new builtin, git-rebase--helper. Once that is in place, we can work gradually on tackling the rest of the technical debt. Note that the rebase--helper needs to learn about the transient --ff/--no-ff options of git-rebase, as the corresponding flag is not persisted to, and re-read from, the state directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08tag: generate useful reflog messageLibravatar Cornelius Weig1-1/+53
When tags are created with `--create-reflog` or with the option `core.logAllRefUpdates` set to 'always', a reflog is created for them. So far, the description of reflog entries for tags was empty, making the reflog hard to understand. For example: 6e3a7b3 refs/tags/test@{0}: Now, a reflog message is generated when creating a tag, following the pattern "tag: tagging <short-sha1> (<description>)". If GIT_REFLOG_ACTION is set, the message becomes "$GIT_REFLOG_ACTION (<description>)" instead. If the tag references a commit object, the description is set to the subject line of the commit, followed by its commit date. For example: 6e3a7b3 refs/tags/test@{0}: tag: tagging 6e3a7b3398 (Git 2.12-rc0, 2017-02-03) If the tag points to a tree/blob/tag objects, the following static strings are taken as description: - "tree object" - "blob object" - "other tag object" Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08receive-pack: avoid duplicates between our refs and alternatesLibravatar Jeff King1-1/+3
We de-duplicate ".have" refs among themselves, but never check if they are duplicates of our local refs. It's not unreasonable that they would be if we are a "--shared" or "--reference" clone of a similar repository; we'd have all the same tags. We can handle this by inserting our local refs into the oidset, but obviously not suppressing duplicates (since the refnames are important). Note that this also switches the order in which we advertise refs, processing ours first and then any alternates. The order shouldn't matter (and arguably showing our refs first makes more sense). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08receive-pack: treat namespace .have lines like alternatesLibravatar Jeff King1-3/+7
Namely, de-duplicate them. We use the same set as the alternates, since we call them both ".have" (i.e., there is no value in showing one versus the other). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08receive-pack: fix misleading namespace/.have commentLibravatar Jeff King1-4/+1
The comment claims that we handle alternate ".have" lines through this function, but that hasn't been the case since 85f251045 (write_head_info(): handle "extra refs" locally, 2012-01-06). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08receive-pack: use oidset to de-duplicate .have linesLibravatar Jeff King1-14/+12
If you have an alternate object store with a very large number of refs, the peak memory usage of the sha1_array can grow high, even if most of them are duplicates that end up not being printed at all. The similar for_each_alternate_ref() code-paths in fetch-pack solve this by using flags in "struct object" to de-duplicate (and so are relying on obj_hash at the core). But we don't have a "struct object" at all in this case. We could call lookup_unknown_object() to get one, but if our goal is reducing memory footprint, it's not great: - an unknown object is as large as the largest object type (a commit), which is bigger than an oidset entry - we can free the memory after our ref advertisement, but "struct object" entries persist forever (and the receive-pack may hang around for a long time, as the bottleneck is often client upload bandwidth). So let's use an oidset. Note that unlike a sha1-array it doesn't sort the output as a side effect. However, our output is at least stable, because for_each_alternate_ref() will give us the sha1s in ref-sorted order. In one particularly pathological case with an alternate that has 60,000 unique refs out of 80 million total, this reduced the peak heap usage of "git receive-pack . </dev/null" from 13GB to 14MB. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-08for_each_alternate_ref: pass name/oid instead of ref structLibravatar Jeff King1-2/+4
Breaking down the fields in the interface makes it easier to change the backend of for_each_alternate_ref to something that doesn't use "struct ref" internally. The only field that callers actually look at is the oid, anyway. The refname is kept in the interface as a plausible thing for future code to want. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
2017-02-03rev-parse: add '--absolute-git-dir' optionLibravatar SZEDER Gábor1-8/+18
The output of 'git rev-parse --git-dir' can be either a relative or an absolute path, depending on whether the current working directory is at the top of the worktree or the .git directory or not, or how the path to the repository is specified via the '--git-dir=<path>' option or the $GIT_DIR environment variable. And if that output is a relative path, then it is relative to the directory where any 'git -C <path>' options might have led us. This doesn't matter at all for regular scripts, because the git wrapper automatically takes care of changing directories according to the '-C <path>' options, and the scripts can then simply follow any path returned by 'git rev-parse --git-dir', even if it's a relative path. Our Bash completion script, however, is unique in that it must run directly in the user's interactive shell environment. This means that it's not executed through the git wrapper and would have to take care of any '-C <path> options on its own, and it can't just change directories as it pleases. Consequently, adding support for taking any '-C <path>' options on the command line into account during completion turned out to be considerably more difficult, error prone and required more subshells and git processes when it had to cope with a relative path to the .git directory. Help this rather special use case and teach 'git rev-parse' a new '--absolute-git-dir' option which always outputs a canonicalized absolute path to the .git directory, regardless of whether the path is discovered automatically or is specified via $GIT_DIR or 'git --git-dir=<path>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>