is there a bash-completion script that supports filename completion? I use mostly mercurial and there I can type:
hg diff test/test_<tab>
and it will show/complete all modified test files. It works for most subcommands, i.e. hg add <tab><tab>
will only list untracked files. It is really handy.
The bash script from git contrib seams to not support this. Are there any alternatives, or how do you work with git on the command line?
Edit 2015
git-completion.bash
supports full filename completion since ~1.8.2
So, let's see how the Mercurial bash completion script does this.
This is the important part:
_hg_status()
{
local files="$(_hg_cmd status -n$1 .)"
local IFS=$'\n'
COMPREPLY=(${COMPREPLY[@]:-} $(compgen -W '$files' -- "$cur"))
}
It gets called here:
_hg_command_specific()
{
case "$cmd" in
[...]
diff)
_hg_status "mar"
;;
[...]
esac
return 0
}
Thus, it is simply a call of hg status -nmar
, and using the output as a list of files for completion.
I think it would not be too hard to patch something similar into the git completion script - we would have to modify __git_diff
here to not do a plain filename + branch completion, but calling git status
instead.
The commands
git status --porcelain | grep '^.[^ ?]' | cut -b 4-
(for git diff --cached
) and
git status --porcelain | grep '^[^ ?]' | cut -b 4-
(for git diff
) seem to output the right thing (if there are no renames).
They both are not useful when diffing to anything other than HEAD, though.
A more general way would be to use
git diff --relative --name-only [--cached] [commit1] [commit2]]
where commit1
and commit2
(and maybe --cached
) come from the already given diff command line.
I implemented the idea outlined above in bash, and patched into git-completion.bash
. If you don't want to change your git-completion.bash
, add these two functions to some bash file and source it after the original git-completion.bash
. It should now work with commands like
git diff -- <tab>
git diff --cached -- <tab>
git diff HEAD^^ -- <tab>
git diff origin/master master -- <tab>
I submitted this as a patch to the git mailing list, let's see what results from this. (I'll update this answer as I get feedback there.)
# Completion for the file argument for git diff.
# It completes only files actually changed. This might be useful
# as completion for other commands as well.
#
# The idea comes from the bash completion for Mercurial (hg),
# which does something similar (but more simple, only difference of
# working directory to HEAD and/or index, if I understand right).
# It (the idea) was brought to us by the question
# http://stackoverflow.com/q/6034472/600500
# from "olt".
__git_complete_changed_files()
{
#
# We use "git diff --name-only --relative" to generate the list,
# but this needs the same --cached and <commit> arguments as the
# command line being constructed.
#
# first grab arguments like --cached and any commit arguments.
local -a args=()
local finish=false
for (( i=1 ; i < cword ; i++)) do
local current_arg=${words[$i]}
# echo checking $current_arg >&2
case $current_arg in
--cached)
args+=( $current_arg )
;;
--)
# finish parsing arguments, the rest are file names
break
;;
-*)
# other options are ignored
;;
*)
if git cat-file -e $current_arg 2> /dev/null
then
case $( git cat-file -t $current_arg ) in
commit|tag)
# commits and tags are added to the command line.
args+=( $current_arg )
# echo adding $current_arg >&2
;;
*)
esac
fi
;;
esac
done
# now we can call `git diff`
COMPREPLY=( $( compgen \
-W "$( git diff --name-only --relative "${args[@]}" -- )" -- $cur ) )
}
_git_diff ()
{
if __git_has_doubledash
then
# complete for the file part: only changed files
__git_complete_changed_files
else
case "$cur" in
--*)
__gitcomp "--cached --staged --pickaxe-all --pickaxe-regex
--base --ours --theirs --no-index
$__git_diff_common_options
"
return
;;
esac
__git_complete_revlist_file
fi
}
Update: Looks like this patch is not wanted in this form, as the current way to complete files is more useful for people which want to check whether there are changes in some subdirectory (e.g. completing when the diff output could be empty). It might be accepted if linked to some configuration variable (with the default being the current behavior). Also, the indenting should be adapted to the standard (see the answer from Junio C Hamano).
I might take another go on it, but can't guarantee this for the near future. If someone else want to do, feel free to take my code, change it and submit it again.
This solves the git diff <tab>
problem for me, put the following in .bashrc:
alias gid='git diff'
__gdiff () {
local cur prev opts
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
prev="${COMP_WORDS[COMP_CWORD-1]}"
opts=$(git status --porcelain | grep '^.[^ ?]' | cut -b 4-)
case "${prev}" in
gid)
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
;;
esac
}
complete -F __gdiff gid
And then do gid <tab>
instead of git diff <tab>
. It may be simplified, but seems to work well as a quick fix.
Not really your desired answer but I wanted to let you know that soon fish (friendly interactive shell) will give you git filename completion support out of the box. It is currently in master with a 2.3.0 release coming soon.
https://github.com/fish-shell/fish-shell/issues/901
https://github.com/fish-shell/fish-shell/pull/2364
https://github.com/fish-shell/fish-shell/commit/c5c59d4acb00674bc37198468b5978f69484c628
If you have a status like this:
$ git status
modified: ../README.md
$ git add <tab>
:/README.md
You can also just type README
and hit tab and it will insert it for you if it is the only match. Friggin nice!
Since 2011, as the OP comments, Git supports full filename completion since ~1.8.2.
But with Git 2.18 (Q2 2018), the shell completion (in contrib/
) that gives list of paths have been optimized somewhat.
See commit 78a2d21 (04 Apr 2018) by Clemens Buchacher (drizzd
).
(Merged by Junio C Hamano -- gitster
-- in commit 3a940e9, 25 Apr 2018)
completion
: improve ls-files
filter performance
From the output of ls-files
, we remove all but the leftmost path
component and then we eliminate duplicates. We do this in a while
loop,
which is a performance bottleneck when the number of iterations is large
(e.g. for 60000 files in linux.git
).
$ COMP_WORDS=(git status -- ar) COMP_CWORD=3; time _git
real 0m11.876s
user 0m4.685s
sys 0m6.808s
Replacing the loop with the cut command improves performance
significantly:
$ COMP_WORDS=(git status -- ar) COMP_CWORD=3; time _git
real 0m1.372s
user 0m0.263s
sys 0m0.167s
The measurements were done with Msys2 bash, which is used by Git for
Windows.
When filtering the ls-files
output we take care not to touch absolute
paths. This is redundant, because ls-files
will never output absolute
paths. Remove the unnecessary operations.
The issue was originally reported Git for Windows issue 1533.