On Tue, Nov 13, 2012 at 6:46 PM, SZEDER Gábor <sze...@ira.uka.de> 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.


>> > 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

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

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to