Git bash-completion with filename support?

2019-01-17 23:21发布

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

4条回答
ら.Afraid
2楼-- · 2019-01-17 23:24

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.

查看更多
劫难
3楼-- · 2019-01-17 23:25

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.

查看更多
forever°为你锁心
4楼-- · 2019-01-17 23:31

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 

enter image description here

You can also just type README and hit tab and it will insert it for you if it is the only match. Friggin nice!

查看更多
小情绪 Triste *
5楼-- · 2019-01-17 23:37

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.

查看更多
登录 后发表回答