Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > Junio C Hamano wrote: >> __gitcomp_nl "$(__git_heads)" "$pfx" "$cur_" "." >> __gitcomp_nl_append $"autosetupmerge\nautosetuprebase\n" "$pfx" "$cur_" " " > > This is not a bad idea at all. I'm just afraid that we might be > leaving open ends: What happens if the $pfx isn't the same in both > cases? Who keeps track of the index "i" of COMPREPLY (it's currently a > local variable)? If we make it global, doesn't every function that > deals with COMPREPLY be careful to reset it? I am not sure what you are worried about $pfx; what does it do when you have strings with different prefix in COMPREPLY? If it breaks, then the answer is "don't do it then". Doesn't an array know its own length and give you a way to ask? > More importantly, can you see a usecase for more than two completion classes? I am not sure why you think it is more important. Somebody lacked forsight and designed an interface that would allow only one "completion classes" (whatever that means) and called the result sufficient. It has been sufficient for a long time. Later you came, found that one was not enough, and added an inteface that would allow only two, and called the result sufficient. See a pattern? Anticipating unforseen possibilities for enhancement and preparing an easy way to support them without overengineering is what the "prepare an appending variant" suggestion is about, and by definition, unforseen possibilities have not been seen yet ;-) Imagine if one is flipping 47 topic branches from 6 contributors whose names all begin with 'j'. I can see that such a person would appreciate if "git config branch.j<TAB>" did not dump all 47 topics at once but offered "jc/ jk/ jl/ jm/ jn/ js/" instead, and then a follow-up completion of "git config branch.jk/<TAB>" expanded to names of topics from that single contributor "jk". Wouldn't the way to give these be either to return these two-letter hierarchy names with slash as the suffix or to return list of two-letter plus a slash with an empty suffix? Either way, that is using something different from a dot or a space, so that may count as the third, I guess. -- 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