On Sat, Aug 18 2018, Jonathan Nieder wrote: > Hi, > > Michael Muré wrote: > >> I released today git-bug, a distributed bug tracker that embeds in >> git. It use git's internal storage to store bugs information in a way >> that can be merged without conflict. You can push/pull to the normal >> git remote you are already using to interact with other people. Normal >> code and bugs are completely separated and no files are added in the >> regular branches. > > 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? Addressing the more general issue, if we're concerned with 3rd party tools usurping the core namespace trying to convince individual authors of 3rd party tools to change the names of those tools to something more unique is pissing in the wind. That's never going to make a dent in the vast amount of git-whatever tools, most of which won't be discussed as ideas on this mailing list before they're released. I think we basically have these options: 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 (re parallel on-list discussion; "git annex" could also be a "git commit --amend" alias). 2) #1, but hope we catch new tools early enough to convince their authors to change the names. 3) Make some structural change to git where only things we ourselves compile get to be called as "git <whatever>", and you'd need to call e.g. "git-bug" as "git ext::bug" or something. We'd need to have a large hardcoded list of older tools (lfs, annex, ...) to grandfather in if we went for this approach. I think we should just go for #1, and if we're concerned about #1 not being OK we really need something like #3, because #2 isn't going to work. > Separately from that, I'm happy to see progress being made in the > distributed bug tracker world; thanks for that! > > Thanks, > Jonathan
