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

On Sat, Aug 18 2018, Jonathan Nieder wrote:

Hi,

Ævar Arnfjörð Bjarmason wrote:

quoted

On Sat, Aug 18 2018, Jonathan Nieder wrote:

quoted

Michael Muré wrote:

quoted

quoted

quoted

I released today git-bug, a distributed bug tracker

[...]

quoted

quoted

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.

[...]

quoted

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.