From: Manlio Perillo <manlio.perillo@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, szeder@ira.uka.de, peff@peff.net
Subject: Re: [PATCH v5] git-completion.bash: add support for path completion
Date: Tue, 23 Apr 2013 17:25:24 +0200 [thread overview]
Message-ID: <5176A7E4.2070608@gmail.com> (raw)
In-Reply-To: <CAMP44s1TjTiZ9HsXn9YiJ8E6+jC=s+g_tps6AY2ixrrgX=0jnw@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 21/04/2013 12:14, Felipe Contreras ha scritto:
> On Fri, Jan 11, 2013 at 12:48 PM, Manlio Perillo
> <manlio.perillo@gmail.com> wrote:
>> The git-completion.bash script did not implemented full, git aware,
>> support to complete paths, for git commands that operate on files within
>> the current working directory or the index.
>
>> +__git_index_file_list_filter_compat ()
>> +{
>> + local path
>> +
>> + while read -r path; do
>> + case "$path" in
>> + ?*/*) echo "${path%%/*}/" ;;
>> + *) echo "$path" ;;
>> + esac
>> + done
>> +}
>> +
>> +__git_index_file_list_filter_bash ()
>> +{
>> + local path
>> +
>> + while read -r path; do
>> + case "$path" in
>> + ?*/*)
>> + # XXX if we append a slash to directory names when using
>> + # `compopt -o filenames`, Bash will append another slash.
>> + # This is pretty stupid, and this the reason why we have to
>> + # define a compatible version for this function.
>> + echo "${path%%/*}" ;;
>
> Which version of bash is that? It works perfectly fine here with or
> without the /.
>
GNU bash, version 4.1.5(1)-release (i486-pc-linux-gnu)
on a GNU Linux Debian 6
>> +# __git_index_files accepts 1 or 2 arguments:
>> +# 1: Options to pass to ls-files (required).
>> +# Supported options are --cached, --modified, --deleted, --others,
>> +# and --directory.
>> +# 2: A directory path (optional).
>> +# If provided, only files within the specified directory are listed.
>> +# Sub directories are never recursed. Path must have a trailing
>> +# slash.
>> +__git_index_files ()
>> +{
>> + local dir="$(__gitdir)" root="${2-.}"
>> +
>> + if [ -d "$dir" ]; then
>> + __git_ls_files_helper "$root" "$1" | __git_index_file_list_filter |
>> + sort | uniq
>> + fi
>> +}
>> +
>> +# __git_diff_index_files accepts 1 or 2 arguments:
>> +# 1) The id of a tree object.
>> +# 2) A directory path (optional).
>> +# If provided, only files within the specified directory are listed.
>> +# Sub directories are never recursed. Path must have a trailing
>> +# slash.
>> +__git_diff_index_files ()
>> +{
>> + local dir="$(__gitdir)" root="${2-.}"
>> +
>> + if [ -d "$dir" ]; then
>> + __git_diff_index_helper "$root" "$1" | __git_index_file_list_filter |
>> + sort | uniq
>> + fi
>> +}
>
> These two are exactly the same, except one calls
> __git_ls_files_helper, and the other one __git_diff_index_helper,
> can't we make another argument that is and select one or the other
> based on that?
>
They are not exactly the same.
The first function requires, as first parameter, (space separed) options
to pass to ls-files command; the second function, instead, requires the
id of a tree object.
IMHO, using only one function may be confusing.
>> __git_heads ()
>> {
>> local dir="$(__gitdir)"
>> @@ -430,6 +543,46 @@ __git_complete_revlist_file ()
>> }
>>
>>
>> +# __git_complete_index_file requires 1 argument: the options to pass to
>> +# ls-file
>> +__git_complete_index_file ()
>> +{
>> + local pfx cur_="$cur"
>> +
>> + case "$cur_" in
>> + ?*/*)
>> + pfx="${cur_%/*}"
>> + cur_="${cur_##*/}"
>> + pfx="${pfx}/"
>> +
>> + __gitcomp_file "$(__git_index_files "$1" "$pfx")" "$pfx" "$cur_"
>> + ;;
>> + *)
>> + __gitcomp_file "$(__git_index_files "$1")" "" "$cur_"
>> + ;;
>> + esac
>> +}
>> +
>> +# __git_complete_diff_index_file requires 1 argument: the id of a tree
>> +# object
>> +__git_complete_diff_index_file ()
>> +{
>> + local pfx cur_="$cur"
>> +
>> + case "$cur_" in
>> + ?*/*)
>> + pfx="${cur_%/*}"
>> + cur_="${cur_##*/}"
>> + pfx="${pfx}/"
>> +
>> + __gitcomp_file "$(__git_diff_index_files "$1" "$pfx")" "$pfx" "$cur_"
>> + ;;
>> + *)
>> + __gitcomp_file "$(__git_diff_index_files "$1")" "" "$cur_"
>> + ;;
>> + esac
>> +}
>
> These are also exactly the same, we could pass the argument to the
> function above.
>
See previous note.
Regards Manlio Perillo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlF2p+QACgkQscQJ24LbaUQVcACfeYFO8umJDbgTrXWChqqbk69E
CE4AniZFP7PQkOZCbBY+6hZ2gMpNIJTn
=HqAf
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2013-04-23 15:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 18:48 [PATCH v5] git-completion.bash: add support for path completion Manlio Perillo
2013-01-11 22:02 ` Junio C Hamano
2013-01-12 14:52 ` Manlio Perillo
2013-01-13 22:56 ` Junio C Hamano
2013-01-12 12:53 ` Manlio Perillo
2013-01-13 22:46 ` Junio C Hamano
2013-04-21 10:14 ` Felipe Contreras
2013-04-23 15:25 ` Manlio Perillo [this message]
2013-04-27 2:52 ` Felipe Contreras
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5176A7E4.2070608@gmail.com \
--to=manlio.perillo@gmail.com \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=szeder@ira.uka.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.