Re: git-bug: Distributed bug tracker embedded in git

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

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.