On Tue, Apr 17, 2012 at 9:15 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > >> On Tue, Apr 17, 2012 at 6:50 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> Felipe Contreras <felipe.contreras@xxxxxxxxx> 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 -- 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