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

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

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).