On Sat, Aug 18 2018, Jonathan Nieder wrote: > Ævar Arnfjörð Bjarmason wrote: > >> The reason I can drop a "git-whatever" in my $PATH and invoke it as "git >> whatever" is just a historical accident of how git was implemented. > > No. This is a very deliberate design decision, to allow people to > prototype new Git commands (and to create the kind of ecosystem that > allows commands to be implemented outside Git. > > [...] >> So we don't get to say "you never asked us about git-annex, we're using >> that name now" without considering how widely used it is. It's us who >> decided to expose the API of seamlessly integrating 3rd party tools. > > I think we're talking past each other. I haven't proposed any blanket > policy. I'm saying that "git bug" is a bad name for this tool: > > - it's hard to find with search engines > - it conflicts with some likely good future changes to Git > - it assumes that no one else will have some other refinement of the > Git bugtracker concept, that it is the only "git bug" tool > > It's a namespace grab. There's nothing stopping someone from naming a > command "bug", either, but that doesn't make it a good idea. (I'm not > saying that was the intent --- that's just the effect.) > > Meanwhile it looks like a neat tool, and I'm very supportive of the > idea. But you certainly still have not convinced me that the name is > a good idea, or that I shouldn't be bringing this up. > > I'm not sure *what* you're trying to convince me of, actually. I'm not saying the git-bug name is a good idea, or that it isn't. I don't care about this particular case when it comes to naming. I'm just pointing out in the more general case that if someone comes up with a badly named git-xyz it doesn't scale to try to point this out to them before git-xyz is widely deployed. So we must either let it go (solution #1), or come up with some API-level solution that makes it a non-issue (my #3).
