On Tue, Nov 13, 2012 at 6:46 PM, SZEDER Gábor <szeder@xxxxxxxxxx> wrote:
> Hi,
>
> On Tue, Nov 13, 2012 at 03:12:44PM -0500, Marc Khouzam wrote:
>> >> +if [ -n "$1" ] ; then
>> >> + # If there is an argument, we know the script is being executed
>> >> + # so go ahead and run the _git_complete_with_output function
>> >> + _git_complete_with_output "$1" "$2"
>> >
>> > Where does the second argument come from? Below you run this script
>> > as '${__git_tcsh_completion_script} "${COMMAND_LINE}"', i.e. $2 is
>> > never set. Am I missing something?
>>
>> This second argument is optional and, if present, will be put in
>> $COMP_CWORD. If not present, $COMP_CWORD must be computed
>> from $1. Also see comment above _git_complete_with_output ().
>> tcsh does not provide me with this information, so I cannot make use of it.
>> However, I thought it would be more future-proof to allow it for other shells
>> which may have that information.
>>
>> It is not necessary for tcsh, so I can remove if you prefer?
>
> I see. I read those comments and understood what it is about. I was
> just surprised that the code is there to make use of it, yet it's not
> specified when invoking that function.
>
> Since it's a trivial piece of code, I would say let's keep it. Could
> you please add a sentence about it (that it's for possible future
> users and it's not used at the moment) to the commit message for
> future reference?
Will do.
>> >> +complete git 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >> +complete gitk 'p/*/`${__git_tcsh_completion_script} "${COMMAND_LINE}"
>> >> | sort | uniq`/'
>> >
>> > Is the 'sort | uniq' really necessary? After the completion function
>> > returns Bash automatically sorts the elements in COMPREPLY and removes
>> > any duplicates. Doesn't tcsh do the same? I have no idea about tcsh
>> > completion.
>>
>> On my machine, tcsh does not remove duplicates. It does sort the results
>> but that is done after I've run 'uniq', which is too late. I'm not
>> happy about this
>> either, but the other option is to improve git-completion.bash to
>> avoid duplicates,
>> which seemed less justified.
>
> Ok. Then keep it for the time being, and we'll see what we can do to
> avoid those duplicates.
Thanks.
>> > Does the git completion script returns any duplicates at all?
>>
>> It does. 'help' is returned twice for example.
>
> Right. Now that you mentioned it, I remember I noticed it a while
> ago, too. I even wrote a patch to fix it, but not sure what became of
> it. Will try to dig it up.
Thanks for already posting the patch.
>> Also, when completing 'git checkout ' in the git repo, I can see multiple
>> 'todo' branches, as well as 'master', 'pu', 'next', etc.
>>
>> You can actually try it without tcsh by running my proposed version of
>> git-completion.bash like this:
>>
>> cd git/contrib/completion
>> bash git-completion.bash "git checkout " | sort | uniq --repeated
>
> Interesting, I can't reproduce. Are the duplicates also there, if you
> start a bash, source git-completion.bash, and run __git_refs ?
Running __git_refs does not show the duplicates, but running
__git refs '' 1
does show them.
That second parameter causes __git_refs to
"use the guess heuristic employed by checkout for tracking branches"
I don't quite understand this, but what I can see is that my remote
branches GitHub/master and origin/master each cause another
'master' to be listed:
$ __git_refs '' 1|grep master
master
GitHub/master
origin/master
master
master
All fixes are done and I'll post a second version of the patch
as soon as I can figure out the formatting properly.
Thanks again
Marc
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html