On Sat, May 5, 2012 at 6:47 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Felipe Contreras wrote: >> On Sat, May 5, 2012 at 5:54 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > >>> Following a convention similar to the bash-completion project's >>> proposed future convention doesn't really help compatibility. If we >>> want to be able to include this function in that project without >>> change some day, we'd have to call it _BC_git_complete. :) >> >> No, that's for bash-completion's functions, this is a git bash >> completion function. > > Please read again. "If we want to be able to include this ...". I > assume we do not, but that would be the reason to follow their > convention to the letter. We don't know what is their convention, so we can't possibly follow it to the letter. From the looks of it, they want _BC_* for *their* public APIs, we shouldn't be using that: http://article.gmane.org/gmane.comp.shells.bash.completion.devel/3158 > [...] >> But wasn't you the one that suggested we follow the bash-completion's >> guidelines, or that was only when the guidelines happened to match >> your preference? > > Sorry for the lack of clarity before. I like to hope that "Because > Jonathan said so" is _never_ the only justification for putting up > with a technical change you disagree with. And I'd like to think that when you filibuster a discussion there's a good reason for it. > In this instance, my > personal justification was "Because our completion scripts are already > using this convention, which happens to come from bash-completion's > guidelines and here are the reasons behind those". I see, so the bash-completion guidelines was not the main point, that was just extra sauce? Then it would follow that if the bash-completion guidelines were different, that wouldn't change your main argument, because the reasons would be the same. But when I argued that there were no such bash-completion guidelines you didn't just drop this side-argument, you pressed on it and even included the bash-completion mailing list. So all the discussion about the existence of these guidelines was pointless? I am going to refrain from expressing what I think of this. > Also, I think you have misunderstood me. I was asking Gábor for input > because you were proposing changing a convention and I thought Gábor > had been maintaining the completion scripts. I was not trying to say > "Please don't do this". > > I was not inviting you to argue with me. Then I'm going to ignore your arguments about bash-completion guidelines. This is what I propose: 1) We name the new function __git_complete; this would be a temporary name, the function would not be meant to be public 2) We discuss later what would be the namespace for public functions, and rename, or add wrappers for them (e.g. _GIT_ps1, _GIT_complete) 3) We standardize the odd functions: __gitdir -> __git_dir Cheers. -- 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