On Sat, Aug 18 2018, Jonathan Nieder wrote: > Hi, > > Ævar Arnfjörð Bjarmason wrote: >> On Sat, Aug 18 2018, Jonathan Nieder wrote: >>> Michael Muré wrote: > >>>> I released today git-bug, a distributed bug tracker > [...] >>> I am a bit unhappy about the namespace grab. Not for trademark >>> reasons: the Git trademark rules are pretty clear about this kind of >>> usage being okay. Instead, the unhappiness comes because a future Git >>> command like "git bug" to produce a bug report with appropriate >>> diagnostics for a bug in Git seems like a likely and useful thing to >>> get added to Git some day. And now the name's taken. >>> >>> Is it too late to ask if it's possible to come up with a less generic >>> name? >> >> Wouldn't we call such a thing "git-reportbug", or "git gitbug", with >> reference to Debian reportbug or perl's perlbug? > > I hope you're kidding about "git gitbug". It sounds a bit silly, but such a tool is going to be rarely used enough that we probably don't want to squat a 3 letter command to invoke it. > [...] >> 1) Accept the status quo where people do create third party tools, much >> of which are way too obscure to matter (e.g. I'm sure someone's >> created a tool/alias called range-diff before, but we didn't >> care). >> >> If those tools become popular enough in the wild they get own that >> namespace, e.g. we're not going to ship a "git-annex" or "git-lfs" >> ourselves implementing some unrelated features > > That's fair. Let me spell out my thinking a little more. > > This framework would lead me to rephrase my question to Michael a > different way. Instead of saying that I'm not happy with the > namespace grab, I should say something more severe: > > Don't be surprised if Git itself makes a "git bug" command in the > future, and be prepared to rename. > > Is that preferable, in your opinion? We're not going to make some blanket policy that doesn't recognize the difference between say git-lfs and git-tool_nobody_has_ever_heard_of, and then decide that it would be just as reasonable for us to ship a new git-lfs ourselves (which would do something different) as it were for us to ship git-tool_nobody_has_ever_heard_of. 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. But because that feature has been exposed since the very beginning it's become an implicit API. There's thousands of git-whatever tools, and people do use these. The likes of git-lfs and git-annex are used a *lot* more than some builtins we ship. 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.
