This can be prohibitively slow on large repositories (minutes!).
While regrettable, no user is going to like waiting that long.
Work towards #3342, rerun of #3230.
Many thanks to @gladhorn for the idea!
Offering auto completion for existing commits is great, but on big
repositories, it suddenly becomes really slow, even with fast hard
disks, since each commit is read and then a line processed for it.
Instead limit to the last 500 commits (arbitrary number) which still
feels fast. Going back further in history can easily and more reasonably
done with git log etc.
* git completion: add mergetool
The list of tools is stole from the bash completion file that comes with
git.
* git completion: complete files with merget conflict for mergetool
A few commands (fetch, pull and push at least) take a "repository" (aka
"remote") and then a "refspec" (we currently do branches here).
Fixes#2525 (seems that man is still alive)
I believe apm must have been buggy - example output that I found online
showed `tr` was mangling paths with spaces in it. Should be fixed.
Also, use dscl on OS X in __fish_complete_users.fish like
__fish_print_users.fish already does.
That's probably the part where commit hashes are most used, we can add
the other subcommands later.
This generates a _lot_ of options, so hooking it up everywhere would be
unwise, though our pager helps quite nicely with filtering - typing
"Branch" will filter out the commits, and typing other things will
filter the subjects, which is quite cool.
* Add missing options to `git clone` in order to make the suggestions as
similar to the manual (https://git-scm.com/docs/git-clone) as
possible.
Signed-off-by: mr.Shu <mr@shu.io>
* Make sure that the `git remote` subcommands are not repeatedly
suggested (that is do not suggest a subcommand if there already is one).
* Add both long and short options to `git remote` subcommands where
appropriate.
Signed-off-by: mr.Shu <mr@shu.io>
Not for _everything_ because that causes too many options to be
generated (which is an issue for git as it is), but for modified, staged
and added files - which is where it is most useful.
Fixes#901 as far as I'm concerned.
git has options that can appear before commands, but not all of
them, and some of them need an argument. This means
`__fish_seen_subcommand_from` will give too many false-positives, while
`[ (count $cmd) -eq 2 ]` will give too many false-negatives.
Instead go through all arguments and check if they are in that list of
options that can be before a command and skip the argument for them, if
any.
