summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'sg/completion'Libravatar Junio C Hamano1-85/+165
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 'jk/describe-omit-some-refs'Libravatar Junio C Hamano1-0/+1
"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-16Merge branch 'rs/cocci-check-free-only-null'Libravatar Junio C Hamano1-0/+6
A new coccinelle rule that catches a check of !pointer before the pointer is free(3)d, which most likely is a bug. * rs/cocci-check-free-only-null: cocci: detect useless free(3) calls
2017-02-15Merge branch 'cw/completion'Libravatar Junio C Hamano1-21/+118
More command line completion (in contrib/) for recent additions. * cw/completion: completion: recognize more long-options completion: teach remote subcommands to complete options completion: teach replace to complete options completion: teach ls-remote to complete options completion: improve bash completion for git-add completion: add subcommand completion for rerere completion: teach submodule subcommands to complete options
2017-02-15Merge branch 'rs/swap'Libravatar Junio C Hamano1-0/+28
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-13completion: restore removed line continuating backslashLibravatar SZEDER Gábor1-1/+1
Recent commit 1cd23e9e0 (completion: don't use __gitdir() for git commands, 2017-02-03) rewrapped a couple of long lines, and while doing so it inadvertently removed a '\' from the end of a line, thus breaking completion for 'git config remote.name.push <TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-11cocci: detect useless free(3) callsLibravatar René Scharfe1-0/+6
Add a semantic patch for removing checks that cause free(3) to only be called with a NULL pointer, as that must be a programming mistake. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-10Merge branch 'ew/complete-svn-authorship-options'Libravatar Junio C Hamano1-2/+2
Correct command line completion (in contrib/) on "git svn" * ew/complete-svn-authorship-options: completion: fix git svn authorship switches
2017-02-10Merge branch 'bw/push-submodule-only'Libravatar Junio C Hamano1-1/+1
Add missing documentation update to a recent topic. * bw/push-submodule-only: completion: add completion for --recurse-submodules=only doc: add doc for git-push --recurse-submodules=only
2017-02-06completion: fix git svn authorship switchesLibravatar Eric Wong1-2/+2
--add-author-from and --use-log-author are for "git svn dcommit", not "git svn (init|clone)" Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: recognize more long-optionsLibravatar Cornelius Weig1-9/+20
Command completion only recognizes a subset of the available options for the various git commands. The set of recognized options needs to balance between having all useful options and to not clutter the terminal. This commit adds all long-options that are mentioned in the man-page synopsis of the respective git command. Possibly dangerous options are not included in this set, to avoid accidental data loss. The added options are: - apply: --recount --directory= - archive: --output - branch: --column --no-column --sort= --points-at - clone: --no-single-branch --shallow-submodules - commit: --patch --short --date --allow-empty - describe: --first-parent - fetch, pull: --unshallow --update-shallow - fsck: --name-objects - grep: --break --heading --show-function --function-context --untracked --no-index - mergetool: --prompt --no-prompt - reset: --keep - revert: --strategy= --strategy-option= - shortlog: --email - tag: --merged --no-merged --create-reflog Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Helped-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: teach remote subcommands to complete optionsLibravatar Cornelius Weig1-7/+38
Git-remote needs to complete remote names, its subcommands, and options thereof. In addition to the existing subcommand and remote name completion, do also complete the options - add: --track --master --fetch --tags --no-tags --mirror= - set-url: --push --add --delete - get-url: --push --all - prune: --dry-run Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: teach replace to complete optionsLibravatar Cornelius Weig1-0/+6
Git-replace needs to complete references and its own options. In addition to the existing references completions, do also complete the options --edit --graft --format= --list --delete. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: teach ls-remote to complete optionsLibravatar Cornelius Weig1-0/+6
ls-remote needs to complete remote names and its own options. In addition to the existing remote name completions, do also complete the options --heads, --tags, --refs, --get-url, and --symref. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: improve bash completion for git-addLibravatar Cornelius Weig1-3/+7
Command completion for git-add did not recognize some long-options. This commits adds completion for all long-options that are mentioned in the man-page synopsis. In addition, if the user specified `--update` or `-u`, path completion will only suggest modified tracked files. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: add subcommand completion for rerereLibravatar Cornelius Weig1-0/+11
Managing recorded resolutions requires command-line usage of git-rerere. Added subcommand completion for rerere and path completion for its subcommand forget. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: teach submodule subcommands to complete optionsLibravatar Cornelius Weig1-2/+30
Each submodule subcommand has specific long-options. Therefore, teach bash completion to support option completion based on the current subcommand. All long-options that are mentioned in the man-page synopsis are added. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: cache the path to the repositoryLibravatar SZEDER Gábor1-17/+29
After the previous changes in this series there are only a handful of $(__gitdir) command substitutions left in the completion script, but there is still a bit of room for improvements: 1. The command substitution involves the forking of a subshell, which has considerable overhead on some platforms. 2. There are a few cases, where this command substitution is executed more than once during a single completion, which means multiple subshells and possibly multiple 'git rev-parse' executions. __gitdir() is invoked twice while completing refs for e.g. 'git log', 'git rebase', 'gitk', or while completing remote refs for 'git fetch' or 'git push'. Both of these points can be addressed by using the __git_find_repo_path() helper function introduced in the previous commit: 1. __git_find_repo_path() stores the path to the repository in a variable instead of printing it, so the command substitution around the function can be avoided. Or rather: the command substitution should be avoided to make the new value of the variable set inside the function visible to the callers. (Yes, there is now a command substitution inside __git_find_repo_path() around each 'git rev-parse', but that's executed only if necessary, and only once per completion, see point 2. below.) 2. $__git_repo_path, the variable holding the path to the repository, is declared local in the toplevel completion functions __git_main() and __gitk_main(). Thus, once set, the path is visible in all completion functions, including all subsequent calls to __git_find_repo_path(), meaning that they wouldn't have to re-discover the path to the repository. So call __git_find_repo_path() and use $__git_repo_path instead of the $(__gitdir) command substitution to access paths in the .git directory. Turn tests checking __gitdir()'s repository discovery into tests of __git_find_repo_path() such that only the tested function changes but the expected results don't, ensuring that repo discovery keeps working as it did before. As __gitdir() is not used anymore in the completion script, mark it as deprecated and direct users' attention to __git_find_repo_path() and $__git_repo_path. Yet keep four __gitdir() tests to ensure that it handles success and failure of __git_find_repo_path() and that it still handles its optional remote argument, because users' custom completion scriptlets might depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: extract repository discovery from __gitdir()Libravatar SZEDER Gábor1-16/+26
To prepare for caching the path to the repository in the following commit, extract the repository discovering part of __gitdir() into the __git_find_repo_path() helper function, which stores the found path in the $__git_repo_path variable instead of printing it. Make __gitdir() a wrapper around this new function. Declare $__git_repo_path local in the toplevel completion functions __git_main() and __gitk_main() to ensure that it never leaks into the environment and influences subsequent completions (though this isn't necessary right now, as __gitdir() is still only executed in subshells, but will matter for the following commit). Adjust tests checking __gitdir() or any other completion function calling __gitdir() to perform those checks in a subshell to prevent $__git_repo_path from leaking into the test environment. Otherwise leave the tests unchanged to demonstrate that this change doesn't alter __gitdir()'s behavior. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: don't guard git executions with __gitdir()Libravatar SZEDER Gábor1-21/+11
Three completion functions, namely __git_index_files(), __git_heads() and __git_tags(), first run __gitdir() and check that the path it outputs exists, i.e. that there is a git repository, and run a git command only if there is one. After the previous changes in this series there are no further uses of __gitdir()'s output in these functions besides those checks. And those checks are unnecessary, because we can just execute those git commands outside of a repository and let them error out. We don't perform such a check in other places either. Remove this check and the __gitdir() call from these functions, sparing the fork()+exec() overhead of the command substitution and the potential 'git rev-parse' execution. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: consolidate silencing errors from git commandsLibravatar SZEDER Gábor1-16/+12
Outputting error messages during completion is bad: they disrupt the command line, can't be deleted, and the user is forced to Ctrl-C and start over most of the time. We already silence stderr of many git commands in our Bash completion script, but there are still some in there that can spew error messages when something goes wrong. We could add the missing stderr redirections to all the remaining places, but instead let's leverage that git commands are now executed through the previously introduced __git() wrapper function, and redirect standard error to /dev/null only in that function. This way we need only one redirection to take care of errors from almost all git commands. Redirecting standard error of the __git() wrapper function thus became redundant, remove them. The exceptions, i.e. the repo-independent git executions and those in the __gitdir() function that don't go through __git() already have their standard error silenced. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: don't use __gitdir() for git commandsLibravatar SZEDER Gábor1-29/+31
Several completion functions contain the following pattern to run git commands respecting the path to the repository specified on the command line: git --git-dir="$(__gitdir)" <cmd> <options> This imposes the overhead of fork()ing a subshell for the command substitution and potentially fork()+exec()ing 'git rev-parse' inside __gitdir(). Now, if neither '--gitdir=<path>' nor '-C <path>' options are specified on the command line, then those git commands are perfectly capable to discover the repository on their own. If either one or both of those options are specified on the command line, then, again, the git commands could discover the repository, if we pass them all of those options from the command line. This means we don't have to run __gitdir() at all for git commands and can spare its fork()+exec() overhead. Use Bash parameter expansions to check the $__git_dir variable and $__git_C_args array and to assemble the appropriate '--git-dir=<path>' and '-C <path>' options if either one or both are present on the command line. These parameter expansions are, however, rather long, so instead of changing all git executions and make already long lines even longer, encapsulate running git with '--git-dir=<path> -C <path>' options into the new __git() wrapper function. Furthermore, this wrapper function will also enable us to silence error messages from git commands uniformly in one place in a later commit. There's one tricky case, though: in __git_refs() local refs are listed with 'git for-each-ref', where "local" is not necessarily the repository we are currently in, but it might mean a remote repository in the filesystem (e.g. listing refs for 'git fetch /some/other/repo <TAB>'). Use one-shot variable assignment to override $__git_dir with the path of the repository where the refs should come from. Although one-shot variable assignments in front of shell functions are to be avoided in our scripts in general, in the Bash completion script we can do that safely. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: respect 'git -C <path>'Libravatar SZEDER Gábor1-5/+14
'git -C <path>' option(s) on the command line should be taken into account during completion, because - like '--git-dir=<path>', it can lead us to a different repository, - a few git commands executed in the completion script do care about in which directory they are executed, and - the command for which we are providing completion might care about in which directory it will be executed. However, unlike '--git-dir=<path>', the '-C <path>' option can be specified multiple times and their effect is cumulative, so we can't just store a single '<path>' in a variable. Nor can we simply concatenate a path from '-C <path1> -C <path2> ...', because e.g. (in an arguably pathological corner case) a relative path might be followed by an absolute path. Instead, store all '-C <path>' options word by word in the $__git_C_args array in the main git completion function, and pass this array, if present, to 'git rev-parse --absolute-git-dir' when discovering the repository in __gitdir(), and let it take care of multiple options, relative paths, absolute paths and everything. Also pass all '-C <path> options via the $__git_C_args array to those git executions which require a worktree and for which it matters from which directory they are executed from. There are only three such cases: - 'git diff-index' and 'git ls-files' in __git_ls_files_helper() used for git-aware filename completion, and - the 'git ls-tree' used for completing the 'ref:path' notation. The other git commands executed in the completion script don't need these '-C <path>' options, because __gitdir() already took those options into account. It would not hurt them, either, but let's not induce unnecessary code churn. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: fix completion after 'git -C <path>'Libravatar SZEDER Gábor1-4/+4
The main completion function finds the name of the git command by iterating through all the words on the command line in search for the first non-option-looking word. As it is not aware of 'git -C's mandatory path argument, if the '-C <path>' option is present, 'path' will be the first such word and it will be mistaken for a git command. This breaks completion in various ways: - If 'path' happens to match one of the commands supported by the completion script, then options of that command will be offered. - If 'path' doesn't match a supported command and doesn't contain any characters not allowed in Bash identifier names, then the completion script does basically nothing and Bash in turn falls back to filename completion for all subsequent words. - Otherwise, if 'path' does contain such an unallowed character, then it leads to a more or less ugly error message in the middle of the command line. The standard '/' directory separator is such a character, and it happens to trigger one of the uglier errors: $ git -C some/path <TAB>sh.exe": declare: `_git_some/path': not a valid identifier error: invalid key: alias.some/path Fix this by skipping 'git -C's mandatory path argument while iterating over the words on the command line. Extend the relevant test with this case and, while at it, with cases that needed similar treatment in the past ('--git-dir', '-c', '--work-tree' and '--namespace'). Additionally, silence the standard error of the 'declare' builtins looking for the completion function associated with the git command and of the 'git config' query for the aliased command. So if git ever learns a new option with a mandatory argument in the future, then, though the completion script will again misbehave, at least the command line will not be utterly disrupted by those error messages. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: don't offer commands when 'git --opt' needs an argumentLibravatar SZEDER Gábor1-0/+11
The main git options '--git-dir', '-c', '-C', '--worktree' and '--namespace' require an argument, but attempting completion right after them lists git commands. Don't offer anything right after these options, thus let Bash fall back to filename completion, because - the three options '--git-dir', '-C' and '--worktree' do actually require a path argument, and - we don't complete the required argument of '-c' and '--namespace', and in that case the "standard" behavior of our completion script is to not offer anything, but fall back to filename completion. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: list short refs from a remote given as a URLLibravatar SZEDER Gábor1-3/+16
e832f5c09680 (completion: avoid ls-remote in certain scenarios, 2013-05-28) turned a 'git ls-remote <remote>' query into a 'git for-each-ref refs/remotes/<remote>/' to improve responsiveness of remote refs completion by avoiding potential network communication. However, it inadvertently made impossible to complete short refs from a remote given as a URL, e.g. 'git fetch git://server.com/repo.git <TAB>', because there is, of course, no such thing as 'refs/remotes/git://server.com/repo.git'. Since the previous commit we tell apart configured remotes, i.e. those that can have a hierarchy under 'refs/remotes/', from others that don't, including remotes given as URL, so we know when we can't use the faster 'git for-each-ref'-based approach. Resurrect the old, pre-e832f5c09680 'git ls-remote'-based code for the latter case to support listing short refs from remotes given as a URL. The code is slightly updated from the original to - take into account the path to the repository given on the command line (if any), and - omit 'ORIG_HEAD' from the query, as 'git ls-remote' will never list it anyway. When the remote given to __git_refs() doesn't exist, then it will be handled by this resurrected 'git ls-remote' query. This code path doesn't list 'HEAD' unconditionally, which has the nice side effect of fixing two more expected test failures. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: don't list 'HEAD' when trying refs completion outside of a repoLibravatar SZEDER Gábor1-2/+6
When refs completion is attempted while not in a git repository, the completion script offers 'HEAD' erroneously. Check early in __git_refs() that there is either a repository or a remote to work on, and return early if neither is given. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: list refs from remote when remote's name matches a directoryLibravatar SZEDER Gábor1-2/+18
If the remote given to __git_refs() happens to match both the name of a configured remote and the name of a directory in the current working directory, then that directory is assumed to be a git repository, and listing refs from that directory will be attempted. This is wrong, because in such a situation git commands (e.g. 'git fetch|pull|push <remote>' whom these refs will eventually be passed to) give precedence to the configured remote. Therefore, __git_refs() should list refs from the configured remote as well. Add the helper function __git_is_configured_remote() that checks whether its argument matches the name of a configured remote. Use this helper to decide how to handle the remote passed to __git_refs(). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: respect 'git --git-dir=<path>' when listing remote refsLibravatar SZEDER Gábor1-5/+17
In __git_refs() the git commands listing refs, both short and full, from a given remote repository are run without giving them the path to the git repository which might have been specified on the command line via 'git --git-dir=<path>'. This is bad, those git commands should access the 'refs/remotes/<remote>/' hierarchy or the remote and credentials configuration in that specified repository. Use the __gitdir() helper only to find the path to the .git directory and pass the resulting path to the 'git ls-remote' and 'for-each-ref' executions that list remote refs. While modifying that 'for-each-ref' line, remove the superfluous disambiguating doubledash. Don't use __gitdir() to check that the given remote is on the file system: basically it performs only a single if statement for us at the considerable cost of fork()ing a subshell for a command substitution. We are better off to perform all the necessary checks of the remote in __git_refs(). Though __git_refs() was the last remaining callsite that passed a remote to __gitdir(), don't delete __gitdir()'s remote-handling part yet, just in case some users' custom completion scriptlets depend on it. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: fix most spots not respecting 'git --git-dir=<path>'Libravatar SZEDER Gábor1-5/+7
The completion script already respects the path to the repository specified on the command line most of the time, here we add the necessary '--git-dir=$(__gitdir)' options to most of the places where git was executed without it. The exceptions where said option is not added are the git invocations: - in __git_refs() which are non-trivial and will be the subject of the following patch, - getting the list of git commands, merge strategies and archive formats, because these are independent from the repository and thus don't need it, and - the 'git rev-parse --git-dir' in __gitdir() itself. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: ensure that the repository path given on the command line existsLibravatar SZEDER Gábor1-0/+1
The __gitdir() helper function prints the path to the git repository to its stdout or stays silent and returns with error when it can't find a repository or when the repository given via $GIT_DIR doesn't exist. This is not the case, however, when the path in $__git_dir, i.e. the path to the repository specified on the command line via 'git --git-dir=<path>', doesn't exist: __gitdir() still outputs it as if it were a real existing repository, making some completion functions believe that they operate on an existing repository. Check that the path in $__git_dir exists and return with error without printing anything to stdout if it doesn't. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03completion: improve __git_refs()'s in-code documentationLibravatar SZEDER Gábor1-3/+5
That "first argument is passed to __gitdir()" statement in particular is not really helpful, and after this series it won't be the case anyway. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-03Merge branch 'pl/complete-diff-submodule-diff'Libravatar Junio C Hamano1-1/+1
The command line completion (in contrib/) learned that "git diff --submodule=" can take "diff" as a recently added option. * pl/complete-diff-submodule-diff: Completion: Add support for --submodule=diff
2017-02-02Merge branch 'rs/absolute-pathdup'Libravatar Junio C Hamano1-0/+6
Code cleanup. * rs/absolute-pathdup: use absolute_pathdup() abspath: add absolute_pathdup()
2017-02-01completion: add completion for --recurse-submodules=onlyLibravatar Cornelius Weig1-1/+1
Command completion for 'git-push --recurse-submodules' already knows to complete some modes. However, the recently added mode 'only' is missing. Adding 'only' to the recognized modes completes the list of non-trivial modes. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31Merge branch 'js/difftool-builtin'Libravatar Junio C Hamano1-0/+481
Rewrite a scripted porcelain "git difftool" in C. * js/difftool-builtin: difftool: hack around -Wzero-length-format warning difftool: retire the scripted version difftool: implement the functionality in the builtin difftool: add a skeleton for the upcoming builtin
2017-01-31Merge branch 'sb/retire-convert-objects-from-contrib'Libravatar Junio C Hamano2-358/+0
Remove an ancient tool left in contrib/. * sb/retire-convert-objects-from-contrib: contrib: remove git-convert-objects
2017-01-30Completion: Add support for --submodule=diffLibravatar Peter Law1-1/+1
Teach git-completion.bash about the 'diff' option to 'git diff --submodule=', which was added in Git 2.11. Signed-off-by: Peter Law <PeterJCLaw@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-30add SWAP macroLibravatar René Scharfe1-0/+28
Add a macro for exchanging the values of variables. It allows users to avoid repetition and takes care of the temporary variable for them. It also makes sure that the storage sizes of its two parameters are the same. Its memcpy(1) calls are optimized away by current compilers. Also add a conservative semantic patch for transforming only swaps of variables of the same type. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26abspath: add absolute_pathdup()Libravatar René Scharfe1-0/+6
Add a function that returns a buffer containing the absolute path of its argument and a semantic patch for its intended use. It avoids an extra string copy to a static buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23describe: teach describe negative pattern matchesLibravatar Jacob Keller1-0/+1
Teach git-describe the `--exclude` option which will allow specifying a glob pattern of tags to ignore. This can be combined with the `--match` patterns to enable more flexibility in determining which tags to consider. For example, suppose you wish to find the first official release tag that contains a certain commit. If we assume that official release tags are of the form "v*" and pre-release candidates include "*rc*" in their name, we can now find the first release tag that introduces the commit abcdef: git describe --contains --match="v*" --exclude="*rc*" abcdef Add documentation, tests, and completion for this change. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19contrib: remove git-convert-objectsLibravatar Stefan Beller2-358/+0
git-convert-objects, originally named git-convert-cache was used in early 2005 to convert ancient repositories where objects are named after the hash of their compressed contents to the current object naming sheme where they are named after the hash of their pre-compression contents. By now the need for conversion of the very early repositories is less relevant, we no longer need to keep it in contrib; remove it. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19difftool: retire the scripted versionLibravatar Johannes Schindelin1-0/+470
It served its purpose, but now we have a builtin difftool. Time for the Perl script to enjoy Florida. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-18Merge branch 'sb/remove-gitview'Libravatar Junio C Hamano2-1362/+0
Retire long unused/unmaintained gitview from the contrib/ area. * sb/remove-gitview: doc: git-gui browser does not default to HEAD doc: gitk: add the upstream repo location doc: gitk: remove gitview reference contrib: remove gitview
2017-01-17Merge branch 'ls/filter-process' into maintLibravatar Junio C Hamano1-2/+6
Doc update. * ls/filter-process: t0021: fix flaky test docs: warn about possible '=' in clean/smudge filter process values
2017-01-17Merge branch 'bb/unicode-9.0' into maintLibravatar Junio C Hamano3-0/+56
The character width table has been updated to match Unicode 9.0 * bb/unicode-9.0: unicode_width.h: update the width tables to Unicode 9.0 update_unicode.sh: remove the plane filter update_unicode.sh: automatically download newer definition files update_unicode.sh: pin the uniset repo to a known good commit update_unicode.sh: remove an unnecessary subshell level update_unicode.sh: move it into contrib/update-unicode
2017-01-07contrib: remove gitviewLibravatar Stefan Beller2-1362/+0
gitview did not have meaningful contributions since 2007, which gives the impression it is either a mature or dead project. In both cases we should not carry it in git.git as the README for contrib states we only want to carry experimental things to give early exposure. Recently a security vulnerability was reported by Javantea, so the decision to either fix the issue or remove the code in question becomes a bit more urgent. Reported-by: Javantea <jvoss@altsci.com> Signed-off-by: Stefan Beller <sbeller@google.com> Acked-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-27Merge branch 'ls/filter-process'Libravatar Junio C Hamano1-2/+6
Doc update. * ls/filter-process: t0021: fix flaky test docs: warn about possible '=' in clean/smudge filter process values
2016-12-27Merge branch 'cp/merge-continue'Libravatar Junio C Hamano1-1/+1
"git merge --continue" has been added as a synonym to "git commit" to conclude a merge that has stopped due to conflicts. * cp/merge-continue: merge: mark usage error strings for translation merge: ensure '--abort' option takes no arguments completion: add --continue option for merge merge: add '--continue' option as a synonym for 'git commit'