kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
René Scharfe	578398071e	add MOVE_ARRAY Similar to COPY_ARRAY (introduced in `60566cbb58`), add a safe and convenient helper for moving potentially overlapping ranges of array entries. It infers the element size, multiplies automatically and safely to get the size in bytes, does a basic type safety check by comparing element sizes and unlike memmove(3) it supports NULL pointers iff 0 elements are to be moved. Also add a semantic patch to demonstrate the helper's intended usage. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
xiaoqiang zhao	5453b83bdf	send-email: --batch-size to work around some SMTP server limit Some email servers (e.g. smtp.163.com) limit the number emails to be sent per session (connection) and this will lead to a faliure when sending many messages. Teach send-email to disconnect after sending a number of messages (configurable via the --batch-size=<num> option), wait for a few seconds (configurable via the --relogin-delay=<seconds> option) and reconnect, to work around such a limit. Also add two configuration variables to give these options the default. Note: We will use this as a band-aid for now, but in the longer term, we should look at and react to the SMTP error code from the server; Xianqiang reports that 450 and 451 are returned by problematic servers. cf. https://public-inbox.org/git/7993e188.d18d.15c3560bcaf.Coremail.zxq_yx_007@163.com/ Signed-off-by: xiaoqiang zhao <zxq_yx_007@163.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
René Scharfe	76d8d45ffb	coccinelle: polish FREE_AND_NULL rules There are two rules for using FREE_AND_NULL in free.cocci, one for pointer types and one for expressions. Both cause coccinelle to remove empty lines and even newline characters between replacements for some reason; consecutive "free(x);/x=NULL;" sequences end up as multiple FREE_AND_NULL calls on the same time. Remove the type rule, as the expression rule already covers it, and rearrange the lines of the latter to place the addition of FREE_AND_NULL between the removals, which causes coccinelle to leave surrounding whitespace untouched. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
A. Wilcox	fdc1ad97c1	subtree: honour USE_ASCIIDOCTOR when set Defining USE_ASCIIDOCTOR=1 when building Git uses asciidoctor over asciidoc when generating DocBook and man page documentation. However, the contrib/subtree module does not presently honour that flag. This causes a build failure when asciidoc is not present on the build system. Instead, adapt the main Documentation/Makefile logic to use asciidoctor when requested. Signed-off-by: A. Wilcox <AWilcox@Wilcox-Tech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ville Skyttä	6412757514	Spelling fixes Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	1b83d1251e	coccinelle: add a rule to make "expression" code use FREE_AND_NULL() A follow-up to the existing "type" rule added in an earlier change. This catches some occurrences that are missed by the previous rule. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	cf9f49ea48	coccinelle: add a rule to make "type" code use FREE_AND_NULL() Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	0c977dbc81	diff-highlight: split code into module The diff-so-fancy project is also written in perl, and most of its users pipe diffs through both diff-highlight and diff-so-fancy. It would be nice if this could be done in a single script. So let's pull most of diff-highlight's code into its own module which can be used by diff-so-fancy. In addition, we'll abstract a few basic items like reading from stdio so that a script using the module can do more processing before or after diff-highlight handles the lines. See the README update for more details. One small downside is that the diff-highlight script must now be built using the Makefile. There are ways around this, but it quickly gets into perl arcana. Let's go with the simple solution. As a bonus, our Makefile now respects the PERL_PATH variable if it is set. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	d78d237bba	completion: add git config credentialCache.ignoreSIGHUP Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	6ecef7379c	completion: add git config credential completions Add missing completions for git config credential: * credential.helper * credential.useHttpPath * credential.username Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	fd1552d59d	completion: add git config advice completions Add missing completions for git config advice: * advice.amWorkDir * advice.pushAlreadyExists * advice.pushFetchFirst * advice.pushNeedsForce * advice.pushNonFFCurrent * advice.pushNonFFMatching * advice.pushUpdateRejected * advice.rmHints * advice.statusUoption Remove completion for git config advice.pushNonFastForward, since it was renamed to pushUpdateRejected in `1184564eac`. The config still works, but is no longer part of the documentation. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	e8dec56770	completion: add git config am.threeWay completion Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	f254eab2e0	completion: add git config core completions Add missing completions for git config core: * core.checkStat * core.commentChar * core.hideDotFiles * core.hooksPath * core.packedRefsTimeout * core.precomposeUnicode * core.protectHFS * core.protectNTFS * core.splitIndex * core.sshCommand Note that some configs are only used for some platforms (hideDotFiles on Windows and precomposeUnicode on Mac). Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	194280427d	completion: add git config gc completions Add missing completion for git config gc options: * gc.aggressiveDepth * gc.autoDetach * gc.logExpiry * gc.worktreePruneExpire Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	2c9a2ae285	docs/config: mention protocol implications of url.insteadOf If a URL rewrite switches the protocol to something nonstandard (like "persistent-https" for "https"), the user may be bitten by the fact that the default protocol restrictions are different between the two. Let's drop a note in insteadOf that points the user in the right direction. It would be nice if we could make this work out of the box, but we can't without knowing the security implications of the user's rewrite. Only the documentation for a particular remote helper can advise one way or the other. Since we do include the persistent-https helper in contrib/ (and since it was the helper in the real-world case that inspired that patch), let's also drop a note there. Suggested-by: Elliott Cable <me@ell.io> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Rikard Falkeborn	9ee4aa95db	completion: add completions for git config commit Add missing completions for git config: * commit.cleanup * commit.gpgSign * commit.verbose Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Thomas Gummerer	3851e4483f	completion: add git stash push When introducing git stash push in `f5727e26e4` ("stash: introduce push verb", 2017-02-19), I forgot to add it to the completion code. Add it now. Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	cedf4e27de	completion: mark bash script as LF-only Without this change, the completion script does not work, as Bash expects its scripts to have line feeds as end-of-line markers (this is particularly prominent in quoted multi-line strings, where carriage returns would slip into the strings as verbatim characters otherwise). This change is required to let t9902-completion pass when Git's source code is checked out with `core.autocrlf = true`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	bee286f8f7	git-new-workdir: mark script as LF-only Bash does not handle scripts with CR/LF line endings correctly, therefore they have to be forced to LF-only line endings. Funnily enough, this fixes t3000-ls-files-others and t1021-rerere-in-workdir when git.git was checked out with core.autocrlf=true, as these test still use git-new-workdir (once `git worktree` is no longer marked as experimental, both scripts probably want to be ported to using that command instead). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	0dab2468ee	clone: add a --no-tags option to clone without tags Add a --no-tags option to clone without fetching any tags. Without this change there's no easy way to clone a repository without also fetching its tags. When supplying --single-branch the primary remote branch will be cloned, but in addition tags will be followed & retrieved. Now --no-tags can be added --single-branch to clone a repository without tags, and which only tracks a single upstream branch. This option works without --single-branch as well, and will do a normal clone but not fetch any tags. Many git commands pay some fixed overhead as a function of the number of references. E.g. creating ~40k tags in linux.git will cause a command like `git log -1 >/dev/null` to run in over a second instead of in a matter of milliseconds, in addition numerous other things will slow down, e.g. "git log <TAB>" with the bash completion will slowly show ~40k references instead of 1. The user might want to avoid all of that overhead to simply use a repository like that to browse the "master" branch, or something like a CI tool might want to keep that one branch up-to-date without caring about any other references. Without this change the only way of accomplishing this was either by manually tweaking the config in a fresh repository: git init git && cat >git/.git/config <<EOF && [remote "origin"] url = git@github.com:git/git.git tagOpt = --no-tags fetch = +refs/heads/master:refs/remotes/origin/master [branch "master"] remote = origin merge = refs/heads/master EOF cd git && git pull Which requires hardcoding the "master" name, which may not be the main --single-branch would have retrieved, or alternatively by setting tagOpt=--no-tags right after cloning & deleting any existing tags: git clone --single-branch git@github.com:git/git.git && cd git && git config remote.origin.tagOpt --no-tags && git tag -l \| xargs git tag -d Which of course was also subtly buggy if --branch was pointed at a tag, leaving the user in a detached head: git clone --single-branch --branch v2.12.0 git@github.com:git/git.git && cd git && git config remote.origin.tagOpt --no-tags && git tag -l \| xargs git tag -d Now all this complexity becomes the much simpler: git clone --single-branch --no-tags git@github.com:git/git.git Or in the case of cloning a single tag "branch": git clone --single-branch --branch v2.12.0 --no-tags git@github.com:git/git.git Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Stephen Kent	93fdf301de	status: add color config slots for branch info in "--short --branch" Add color config slots to be used in the status short-format when displaying local and remote tracking branch information. [jc: rebased on top of Peff's fix to 'git status' and tweaked the test to check both local and remote-tracking branch output] Signed-off-by: Stephen Kent <smkent@smkent.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Jeff King	60e71bbcea	completion: optionally disable checkout DWIM When we complete branch names for "git checkout", we also complete remote branch names that could trigger the DWIM behavior. Depending on your workflow and project, this can be either convenient or annoying. For instance, my clone of gitster.git contains 74 local "jk/*" branches, but origin contains another 147. When I want to checkout a local branch but can't quite remember the name, tab completion shows me 251 entries. And worse, for a topic that has been picked up for pu, the upstream branch name is likely to be similar to mine, leading to a high probability that I pick the wrong one and accidentally create a new branch. This patch adds a way for the user to tell the completion code not to include DWIM suggestions for checkout. This can already be done by typing: git checkout --no-guess jk/<TAB> but that's rather cumbersome. The downside, of course, is that you no longer get completion support when you _do_ want to invoke the DWIM behavior. But depending on your workflow, that may not be a big loss (for instance, in git.git I am much more likely to want to detach, so I'd type "git checkout origin/jk/<TAB>" anyway). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	723c1d526f	completion: expand "push --delete <remote> <ref>" for refs on that <remote> Change the completion of "push --delete <remote> <ref>" to complete refs on that <remote>, not all refs. Before this cloning git.git and doing "git push --delete origin p<TAB>" will complete nothing, since a fresh clone of git.git will have no "pu" branch, whereas origin/p<TAB> will uselessly complete origin/pu, but fully qualified references aren't accepted by "--delete". Now p<TAB> will complete as "pu". The completion of giving --delete later, e.g. "git push origin --delete p<TAB>" remains unchanged, this is a bug, but is a general existing limitation of the bash completion, and not how git-push is documented, so I'm not fixing that case, but adding a failing TODO test for it. The testing code was supplied by SZEDER Gábor in <20170421122832.24617-1-szeder.dev@gmail.com> with minor setup modifications on my part. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Reviewed-by: SZEDER Gábor <szeder.dev@gmail.com> Test-code-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Junio C Hamano	fba275dc93	contrib/git-resurrect.sh: do not write \t for HT in sed scripts Just like we did in `0d1d6e50` ("t/t7003: replace \t with literal tab in sed expression", 2010-08-12), avoid writing "\t" for HT in sed scripts, which is not portable. Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Ævar Arnfjörð Bjarmason	ac3f5a3468	ref-filter: add --no-contains option to tag/branch/for-each-ref 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>	8 years ago
SZEDER Gábor	41d2716cdc	completion: offer ctags symbol names for 'git log -S', '-G' and '-L:' Just like in the case of search patterns for 'git grep', see `29eec71f2` (completion: match ctags symbol names in grep patterns, 2011-10-21)), a common thing to look for using 'git log -S', '-G' and '-L:' is the name of a symbol. Teach the completion for 'git log' to offer ctags symbol names after these options, both in stuck and in unstuck forms. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	2f779f9176	completion: extract completing ctags symbol names into helper function The previous commit doubled the number of __git_match_ctag()'s positional parameters, and, to keep the position of existing parameters for the sake of backwards compatibility, the prefix, current word and suffix parameters ended up in different order than in other functions accepting the same parameters. Then there is a condition checking the existence of the tag file before invoking this function. We could still live with this if there were only a single callsite, but the next commit will add a few more, so it's worth providing a cleaner interface. Add the wrapper function __git_complete_symbol(), which encompasses the condition for checking the presence of the tag file and filling COMPREPLY, and accepts '--opt=val'-style options with default values that keep callsites simpler. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	7826a7865c	completion: put matching ctags symbol names directly into COMPREPLY The one-liner awk script in __git_match_ctag() listing ctags symbol names for 'git grep <TAB>' is already smart enough to list only symbol names matching the current word to be completed. Extend this helper function to accept prefix and suffix parameters to be prepended and appended, respectively, to each listed symbol name in the awk script, so its output won't require any additional processing or filtering in the completion script before being handed over to Bash. Use the faster __gitcomp_direct() helper instead of __gitcomp_nl() to fill the fully processed matching symbol names into Bash's COMPREPLY array. Right after 'git grep <TAB>' in current git.git with 14k+ symbol names in the tag file, best of five: Before: $ time __gitcomp_nl "$(__git_match_ctag "" tags)" real 0m0.178s user 0m0.176s sys 0m0.000s After: $ time __gitcomp_direct "$(__git_match_ctag "" tags "" " ")" real 0m0.058s user 0m0.048s sys 0m0.008s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	227307a639	completion: speed up branch and tag completion Modify __git_heads() and __git_tags() and the few callsites they have, so we can let 'git for-each-ref' do all the hard work and these functions' output won't need any further processing or filtering before being handed over to Bash, resulting in faster branch and tag completion. These are some of the same tricks used in the previous commits to speed up refs completion, namely: - Extend both functions to accept prefix, current word and suffix positional parameters, all optional and all empty by default to keep the parameterless behavior unaltered. - Specify appropriate globbing patterns to 'git for-each-ref' to list only branches or tags matching the given current word parameter. - Modify the 'git for-each-ref --format=<...>' to include the given prefix and suffix. - Adjust all callsites to specify the proper prefix, current word and suffix parameters, and to fill COMPREPLY using __gitcomp_direct(). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	745d655dc9	completion: fill COMPREPLY directly when completing fetch refspecs The __git_complete_fetch_refspecs() has to iterate over __git_refs()'s output anyway to turn the listed matching refs into refspecs, and it knows about the prefix and suffix that has to be added to each refspec. Modify this function to add the prefix and suffix to each refspec while iterating and feed the result, since it doesn't need further processing, to the new __gitcomp_direct() helper added in the previous commit, because it should be faster when there are a lot of refspecs to list. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	fef56eb006	completion: fill COMPREPLY directly when completing refs __gitcomp_nl() iterates over all the possible completion words it gets as argument - filtering matching words, - appending a trailing space to each matching word (in all but two cases), - prepending a prefix to each matching word (when completing words after e.g. '--option=<TAB>' or 'master..<TAB>'), and - adding each matching word to the COMPREPLY array. This takes a while when a lot of refs are passed to __gitcomp_nl(). The previous changes in this series ensure that __git_refs() lists only refs matching the current word to be completed, making a second filtering in __gitcomp_nl() redundant. Adding the necessary prefix and suffix could be done in __git_refs() as well: - When refs come from 'git for-each-ref', then that prefix and suffix could be added much more efficiently using a 'git for-each-ref' format containing said prefix and suffix. Care should be taken, though, because that prefix might contain 'for-each-ref' format specifiers as part of the left hand side of a '..' range or '...' symmetric difference notation or fetch/push/etc. refspec, e.g. 'git log "evil-%(refname)..br<TAB>'. Doubling every '%' in the prefix will prevent 'git for-each-ref' from interpolating any of those contained specifiers. - When refs come from 'git ls-remote', then that prefix and suffix can be added in the shell loop that has to process 'git ls-remote's output anyway. - Finally, the prefix and suffix can be added to that handful of potentially matching symbolic and pseudo refs right away in the shell loop listing them. And then all what is still left to do is to assign a bunch of newline-separated words to a shell array, which can be done without a shell loop iterating over each word, basically making all of __gitcomp_nl() unnecessary for refs completion. Add the helper function __gitcomp_direct() to fill the COMPREPLY array with prefiltered and preprocessed words without any additional processing, without a shell loop, with just one single compound assignment. Modify __git_refs() to accept prefix and suffix parameters and add them to each and every listed ref as described above. Modify __git_complete_refs() to pass the prefix and suffix parameters to __git_refs() and to feed __git_refs()'s output to __gitcomp_direct() instead of __gitcomp_nl(). This speeds up refs completion when there are a lot of refs matching the current word to be completed. Listing all branches for completion in a repo with 100k local branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs real 0m2.028s user 0m1.692s sys 0m0.344s Before this patch: real 0m1.135s user 0m1.112s sys 0m0.024s After: real 0m0.367s user 0m0.352s sys 0m0.020s On Windows, near the beginning: real 0m13.078s user 0m1.609s sys 0m0.060s Before this patch: real 0m2.093s user 0m1.641s sys 0m0.060s After: real 0m0.683s user 0m0.203s sys 0m0.076s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	400a7553c4	completion: let 'for-each-ref' sort remote branches for 'checkout' DWIMery When listing unique remote branches for 'git checkout's tracking DWIMery, __git_refs() runs the classic '... \|sort \|uniq -u' pattern to filter out duplicate remote branches. Let 'git for-each-ref' do the sorting, sparing the overhead of fork()+exec()ing 'sort' and a stage in the pipeline where potentially relatively large amount of data can be passed between two subsequent pipeline stages. This speeds up refs completion for 'git checkout' a bit when a lot of remote branches match the current word to be completed. Listing a single local and 100k remote branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --track real 0m1.856s user 0m1.816s sys 0m0.060s After: real 0m1.550s user 0m1.512s sys 0m0.060s On Windows, before: real 0m3.128s user 0m2.155s sys 0m0.183s After: real 0m2.781s user 0m1.826s sys 0m0.136s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	824388d54b	completion: let 'for-each-ref' filter remote branches for 'checkout' DWIMery The code listing unique remote branches for 'git checkout's tracking DWIMery outputs only remote branches that match the current word to be completed, but the filtering is done in a shell loop iterating over all remote refs. Let 'git for-each-ref' do the filtering, as it can do so much more efficiently and we can remove that shell loop entirely. This speeds up refs completion for 'git checkout' considerably when there are a lot of non-matching remote refs to be filtered out. Uniquely completing a branch in a repository with 100k remote branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste --track real 0m1.993s user 0m1.740s sys 0m0.304s After: real 0m0.266s user 0m0.248s sys 0m0.012s On Windows, before: real 0m6.187s user 0m3.358s sys 0m2.121s After: real 0m0.750s user 0m0.015s sys 0m0.090s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	e8cb023433	completion: let 'for-each-ref' strip the remote name from remote branches The code listing unique remote branches for 'git checkout's tracking DWIMery uses a shell parameter expansion in a loop iterating over each listed ref to remove the remote's name from the remote branches, i.e. the leading path component from the short ref. When listing refs from a configured remote repository, '\| sed s///' is used for the same purpose. Let 'git for-each-ref' strip one more leading path component from the refs, i.e. use the format 'refname:strip=3' instead of '=2', making that parameter expansion and 'sed' execution unnecessary. This speeds up refs completion for 'git checkout'. Uniquely completing a branch for 'git checkout maste<TAB>' in a repo with 100k remote branches, all packed, best of five: On Linux, near the beginning of this series, for reference: $ time __git_complete_refs --cur=maste --track real 0m8.185s user 0m6.896s sys 0m1.616s Before this patch: real 0m2.714s user 0m2.344s sys 0m0.436s After: real 0m1.993s user 0m1.740s sys 0m0.304s On Windows, near the beginning: real 1m8.421s user 0m7.591s sys 0m3.557s Before this patch: real 0m8.191s user 0m4.638s sys 0m2.918s After: real 0m6.187s user 0m3.358s sys 0m2.121s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	e896369beb	completion: let 'for-each-ref' and 'ls-remote' filter matching refs When completing refs, several __git_refs() code paths list all the refs from the refs/{heads,tags,remotes}/ hierarchy and then __gitcomp_nl() iterates over those refs in a shell loop to filter out refs not matching the current ref to be completed. This comes with a considerable performance penalty when a repository contains a lot of refs but the current ref can be uniquely completed or when only a handful of refs match the current ref. Reduce the number of iterations in __gitcomp_nl() from the number of refs to the number of matching refs by specifying appropriate globbing patterns to 'git for-each-ref' and 'git ls-remote' to list only those refs that match the current ref to be completed. However, do so only when the ref to match is explicitly given as parameter, because the current word on the command line might contain a prefix like '--option=' or 'branch..'. The __git_complete_refs() and __git_complete_fetch_refspecs() helpers introduced previously in this patch series already call __git_refs() specifying this current ref parameter, so all their callsites, i.e. all places in the completion script doing refs completion, can benefit from this optimization. Furthermore, list only those symbolic and pseudo refs that match the current ref to be completed. Though it doesn't matter at all in itself performance-wise, it will allow us further significant optimizations later in this series. This speeds up refs completion considerably when there are a lot of non-matching refs to be filtered out. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m0.831s user 0m0.808s sys 0m0.028s After: real 0m0.119s user 0m0.104s sys 0m0.008s On Windows, before: real 0m1.480s user 0m1.031s sys 0m0.060s After: real 0m0.377s user 0m0.015s sys 0m0.030s Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	b2b6811451	completion: don't disambiguate short refs When the completion script lists short refs it does so using the 'git for-each-ref' format 'refname:short', which makes sure that all listed refs are unambiguous. While disambiguating refs is technically correct in this case, as opposed to the cases discussed in the previous patch, this disambiguation involves several stat() syscalls for each ref, thus, unfortunately, comes at a steep cost especially on Windows and/or when there are a lot of refs to be listed. A user of Git for Windows reported[1] 'git checkout <TAB>' taking ~11 seconds in a repository with just about 4000 refs. However, it's questionable whether ambiguous refs are really that bad to justify that much extra cost: - Ambiguous refs are not that common, - even if a repository contains ambiguous refs, they only hurt when the user actually happens to want to do something with one of the ambiguous refs, and - the issue can be easily circumvented by renaming those ambiguous refs. - On the other hand, apparently not that many refs are needed to make refs completion unacceptably slow on Windows, - and this slowness bites each and every time the user attempts refs completion, even when the repository doesn't contain any ambiguous refs. - Furthermore, circumventing the issue might not be possible or might be considerably more difficult and requires various trade-offs (e.g. working in a repository with only a few selected important refs while keeping a separate repository with all refs for reference). Arguably, in this case the benefits of technical correctness are rather minor compared to the price we pay for it, and we are better off opting for performance over correctness. Use the 'git for-each-ref' format 'refname:strip=2' to list short refs to spare the substantial cost of disambiguating. This speeds up refs completion considerably. Uniquely completing a branch in a repository with 100k local branches, all packed, best of five: On Linux, before: $ time __git_complete_refs --cur=maste real 0m1.662s user 0m1.368s sys 0m0.296s After: real 0m0.831s user 0m0.808s sys 0m0.028s On Windows, before: real 0m12.457s user 0m1.016s sys 0m0.092s After: real 0m1.480s user 0m1.031s sys 0m0.060s [1] - https://github.com/git-for-windows/git/issues/524 Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	3ad8ea7ccc	completion: don't disambiguate tags and branches When the completion script has to list only tags or only branches, it uses the 'git for-each-ref' format 'refname:short', which makes sure that all listed tags and branches are unambiguous. However, disambiguating tags and branches in these cases is wrong, because: - __git_tags(), the helper function listing possible tagname arguments for 'git tag', lists an ambiguous tag 'refs/tags/ambiguous' as 'tags/ambiguous'. Its only consumer, 'git tag' expects its tagname argument to be under 'refs/tags/', thus it interprets that abgiguous tag as 'refs/tags/tags/ambiguous'. Clearly wrong. - __git_heads() lists possible branchname arguments for 'git branch' and possible 'branch.<branchname>' configuration subsections. Both of these expect branchnames to be under 'refs/heads/' and misinterpret a disambiguated branchname like 'heads/ambiguous'. Furthermore, disambiguation involves several stat() syscalls for each tag or branch, thus comes at a steep cost especially on Windows and/or when there are a lot of tags or branches to be listed. Use the 'git for-each-ref' format 'refname:strip=2' instead of 'refname:short' to avoid harmful disambiguation of tags and branches in __git_tags() and __git_heads(). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	aed3881359	completion: support excluding full refs Commit `49416ad22` (completion: support excluding refs, 2016-08-24) made possible to complete short refs with a '^' prefix. Extend the support to full refs to make completing '^refs/...' work. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	aa0644f74f	completion: support completing fully qualified non-fast-forward refspecs After 'git fetch <remote> <TAB>' our completion script offers refspecs that will fetch to a local branch with the same name as in the remote repository, e.g. 'master:master'. This also completes non-fast-forward refspecs, i.e. after a '+' prefix like '+master:master', and fully qualified refspecs, e.g. 'refs/heads/master:refs/heads/master'. However, it does not complete non-fast-forward fully qualified refspecs (or fully qualified refspecs following any other prefix, e.g. '--option=', though currently no git command supports such an option, but third party git commands might). These refspecs are listed by the __git_refs2() function, which is just a thin wrapper iterating over __git_refs()'s output, turning each listed ref into a refspec. Now, it's certainly possible to modify __git_refs2() and its callsite to pass an extra parameter containing only the ref part of the current word to be completed (to follow suit of the previous commit) to deal with prefixed fully qualified refspecs as well. Unfortunately, keeping the current behavior unchanged in the "no extra parameter" case brings in a bit of subtlety, which makes the resulting code ugly and compelled me to write a 8-line long comment in the proof of concept. Not good. However, since the callsite has to be modified for proper functioning anyway, we might as well leave __git_refs2() as is and introduce a new helper function without backwards compatibility concerns. Add the new function __git_complete_fetch_refspecs() that has all the necessary parameters to do the right thing in all cases mentioned above, including non-fast-forward fully qualified refspecs. This new function can also easier benefit from optimizations coming later in this patch series. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	2ea328a119	completion: support completing full refs after '--option=refs/<TAB>' Completing full refs currently only works when the full ref stands on in its own on the command line, but doesn't work when the current word to be completed contains a prefix before the full ref, e.g. '--option=refs/<TAB>' or 'master..refs/bis<TAB>'. The reason is that __git_refs() looks at the current word to be completed ($cur) as a whole to decide whether it has to list full (if it starts with 'refs/') or short refs (otherwise). However, $cur also holds said '--option=' or 'master..' prefixes, which of course throw off this decision. Luckily, the default action is to list short refs, that's why completing short refs happens to work even after a 'master..<TAB>' prefix and similar cases. Pass only the ref part of the current word to be completed to __git_refs() as a new positional parameter, so it can make the right decision even if the whole current word contains some kind of a prefix. Make this new parameter the 4. positional parameter and leave the 3. as an ignored placeholder for now (it will be used later in this patch series). Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	15b4a16395	completion: wrap __git_refs() for better option parsing __git_refs() currently accepts two optional positional parameters: a remote and a flag for 'git checkout's tracking DWIMery. To fix a minor bug, and, more importantly, for faster refs completion, this series will add three more parameters: a prefix, the current word to be completed and a suffix, i.e. the options accepted by __gitcomp() & friends, and will change __git_refs() to list only refs matching that given current word and to add that given prefix and suffix to the listed refs. However, __git_refs() is the helper function that is most likely used in users' custom completion scriptlets for their own git commands, and we don't want to break those, so - we can't change __git_refs()'s default output format, i.e. we can't by default append a trailing space to every listed ref, meaning that the suffix parameter containing the default trailing space would have to be specified on every invocation, and - we can't change the position of existing positional parameters either, so there would have to be plenty of set-but-empty placeholder positional parameters all over the completion script. Furthermore, with five positional parameters it would be really hard to remember which position means what. To keep callsites simple, add the new wrapper function __git_complete_refs() around __git_refs(), which: - instead of positional parameters accepts real '--opt=val'-style options and with minimalistic option parsing translates them to __git_refs()'s and __gitcomp_nl()'s positional parameters, and - includes the '__gitcomp_nl "$(__git_refs ...)" ...' command substitution to make its behavior match its name and the behavior of other __git_complete_* functions, and to limit future changes in this series to __git_refs() and this new wrapper function. Call this wrapper function instead of __git_refs() wherever possible throughout the completion script, i.e. when __git_refs()'s output is fed to __gitcomp_nl() right away without further processing, which means all callsites except a single one in the __git_refs2() helper. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Michael J Gruber	9f0b4dd0b8	git-prompt: add a describe style for any tags git-prompt has various describe styles, among them "describe" (by annotated tags) and "default" (by exact match with any tag). Add a mode "tag" that describes by any tag, annotated or not. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Sebastian Schuberth	b8686c661d	contrib: git-remote-{bzr,hg} placeholders don't need Python It does not make sense for these placeholder scripts to depend on Python just because the real scripts do. At the example of Git for Windows, we would not even be able to see those warnings as it does not ship with Python. So just use plain shell scripts instead. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
René Scharfe	33ad9ddd0b	strbuf: add strbuf_add_real_path() Add a function for appending the canonized absolute pathname of a given path to a strbuf. It keeps the existing contents intact, as expected of a function of the strbuf_add() family, while avoiding copying the result if the given strbuf is empty. It's more consistent with the rest of the strbuf API than strbuf_realpath(), which it's wrapping. Also add a semantic patch demonstrating its intended usage and apply it to the current tree. Using strbuf_add_real_path() instead of calling strbuf_addstr() and real_path() avoids an extra copy to a static buffer. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
René Scharfe	3f64699ffd	cocci: use ALLOC_ARRAY Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply the transformation on the current source tree. The macro checks for multiplication overflow and infers the element size automatically; the result is shorter and safer code. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	c977eefd55	completion: remove redundant __gitcomp_nl() options from _git_commit() Those two options are specifying the default values that __gitcomp_nl() would use anyway when invoked with no options at all. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	3ba042017a	completion: restore removed line continuating backslash 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>	8 years ago
René Scharfe	ec6cd14c7a	cocci: detect useless free(3) calls 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>	8 years ago
Eric Wong	2cbad17642	completion: fix git svn authorship switches --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>	8 years ago
Cornelius Weig	f483a0aa2a	completion: recognize more long-options 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>	8 years ago

1 2 3 4 5 ...

2627 Commits (edc74bc7f0c6884027e851ef09b2e0c9380dcd45)