From: Felipe Contreras Date: Tue, 17 Apr 2012 20:53:08 GMT Subject: Re: [PATCH v2] completion: add new git_complete helper Message-ID: In-Reply-To: <7v4nsins1j.fsf@alter.siamese.dyndns.org> On Tue, Apr 17, 2012 at 9:15 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> On Tue, Apr 17, 2012 at 6:50 PM, Junio C Hamano wrote: >>> Felipe Contreras writes: >> ... >>>>> And foo_wrap() should also fit into those namespaces. >>>> >>>> Yeah, I don't have a problem with that, just forgot about it. >>>> >>>> But git_complete I think is different. >>> >>> Is git_complete something the user types interactively, or is it meant to >>> be used in their .bashrc to help them complete arguments to their custom >>> scripts that take arguments similar to Git Porcelains? >> >> It's meant for their .bashrc, but can be used interactively, exactly >> like 'complete'. You can type 'complete -o bashdefault -o default -o >> nospace -F _git git' in the command like, but that would rarely >> happen. > > OK, then I do not think "as a public interface it looks somewhat ugly" > (which I happen to think, and I am guessing that you agree with) matters. > It looks to me that it would be sane to follow the convention But that convention is for *private* functions. > to avoid > accidental name clashes with userspace names by naming it "__git_complete" > in that case. What if there are no clashes? Are you saying that even if there are no real clashes, only hypothetical ones, you would still prefer __git_complete? How are people going to distinguish between public and private functions? -- Felipe Contreras