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.
Using this, you can do things like this in a more straight-forward
manner:
foo-init() { CURSOR=0; }
zle -N foo-init
foo=$'Some longer\nbuffer with\nmultiple lines.'
vared -i foo-init foo
If `zrefresh' is not called _after_ the zle-line-init hook, any changes
made to the editor's state (be it changes to $CURSOR or $BUFFER or
called widgets like `clear-screen') will only be picked up after the
first character is typed into the editor.
Generate the patch level using `git describe` rather than relying on the
CVS $Revision$. Need to use the `--tags` option, since currently there
are no annotated tags. The `--long` option should be used so that the
output will always be in the 'tag-commits-hash' format rather than just
naming a tag when that would fully describe the current commit.
Since changes to the patchlevel could now be caused by changes to any
file, force the rule to be called every time that `make` is run. Only
update the file when there are actually changes to prevent unnecessary
rebuilding of other build products (currently just `params.o` and
`zsh`).
