- cherry-pick: allow commit ranges to be specified
- push: option is called --set-upstream and not --set-upstream-to
- status: offer -b,--branch when --porcelain or -z are given
--porcelain and -z don't show the branch info by default, so it
is needed to offer --branch for those options, too.
- checkout: add '--detach' option
- checkout: offer '-l' option when '--orphan' was given
- show-ref: update wording of --head and --heads according to man-page
- config: update default value for color.ui
color-bool was changed to accept a default value as $parts[5]
- add support for 'cygstart' as a valid builtin browser on cygwin
- rebase: add suuport for --autostash and config.autostash
- update builtin browser list
- grep: add --{no,}textconv
- check-ignore: add --no-index
- update-ref: add --stdin -z
- add -C
- pull: add support for --rebase=preserve
- config: add support for http.*. options
- blame: -L can be given multiple times
- config: add support for http.savecookies
- push: add support for --force-with-lease
- diff: --diff-filter: allow lower-case variants (all-but ... specs)
- config: add support for 'fetch.prune' and 'remote.*.prune'
- check-ignore: -z: update message, check-attr: add -z
- config: add diff.orderfile
- revision options: add --exclude
- revision options: add --ignore-missing
- revision options: add --bisect
- rev-parse: add --stuck-long
- merge-base: add --fork-point
- config: implement submodule.*.update completion
- send-email: add --smtp-ssl-cert-path and config options
The output of 'submodule status' is
Xsha1 name (describe)
X being one of -,+,U,[space]
We are only interested in the name part and not the whole line.
Fix the parameter expansions accordingly.
Before this, there were several cases where the completion
would offer the wrong things:
$ git diff branch -- <tab>
would try to complete "changed in workdir files", but needs to
complete all "tree files in HEAD".
$ git diff --cached -- file1 file2 <tab>
would try to complete "changed in workdir files" but needs to
complete "changed in index files".
...
After this change all possible combinations are taken into
account and completion should work properly.
- Ranges with 3 dots would always fail, because the non-greedy
expansion %..(.|)* in __git_committish_range_first would only
remove '..' and never three dots. 'a...b' would end up in 'a.'.
Use ${${1%..*}%.} instead.
- Use a similar approach for __git_committish_range_last.
- Wrap them in another expansion to replace empty results with 'HEAD'.
Git man-page states omitted range ending are being replaced with
HEAD. This rule has to be followed to make completions like
'git log foo.. -- <tab>' work properly.
- Add an additional check to make sure none of the extracted first/last
parts contain additional '..' in invalied ranges such as 'a..b..c'.
This gets rid of the 'TODO:' and ideally saves a few unneded
calls to git rev-parse.
Shell functions are strictly ASCII for maximum portability.
Other files within the distribution may contain UTF-8 characters.
Exception for test files: where they need single character input
with the top bit set, ISO-8859-X is used (X doesn't matter as
we don't need the Euro).
commit: '--null' is documented
relink: '-h,--help' are never documented for subcommands but always exist
verify-tag: '-v,--verbose' are documented with updated description
diff: '--cumulative' is deprecated -> remove
While limiting the completion to __git_changed-in-index_files
makes perfect sense for "git diff", it is wrong to use for
"git rm", because it prevents it from completing files present in
HEAD. Giving --cached to git rm is supposed to
"just remove it from the index, keep the working tree copy"
and is in no way related to the file needing to be
modified in the index in the first place.
diff options:
--cumulative is deprecated --> remove
-G / -S: reword -S to emphase the difference to -G
revision options:
--abbrev: reword, to emphase the --abbrev-commit requirement
this is used in git 1.8's
git checkout <branch>
as a shorthand for
git checkout -b <branch> --track <remote>/<branch>
in case <branch> exists on exactly one remote and is not a local branch
Currently, __git-shortlog () says that 'git shortlog' can only accept
commits as arguments (probably because the official documentation says
this). This is entirely untrue: shortlog can accept
commit-range-or-file, just like log can. Fix the completer by copying
out segments from the __git-log () function.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
The configuration variables branch.*.pushremote and remote.pushdefault
are relatively new, and are currently not completed by ZSH. Fix this.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
When a branch or tag name is completed with zsh in a large git repo, the
completion is slow if the given prefix doesn't match a file or directory in
the current working directory. Testing with linux.git, which contains release
tags like v3.9 and a directory virt/:
git log v<tab>
takes about 0.5 seconds, while
git log v3<tab>
takes about 25 seconds.
(Timed using zsh 4.3.17, on a fairly slow cpu. zsh from git appears to be
quite a bit faster, but the difference between completing v and v3 is still
large.)
The difference between the two is that v<tab> passes the result of v* to git
ls-files while v3<tab> determines that v3* matches no files, and passes an
empty prefix to git ls-files. So git ls-files lists all files in the repo
and passes that on to _multi_parts.
Making git do the expansion of the * after the prefix lets git ls-files v3*
return an empty list, making _multi_parts job easier.
This does not affect the behavior of git log <tab>, but improves the
performance of partial tag and branch tab-completion in the common case where
file names and tag/branch names don't overlap.
