{"thread":{"id":"49156","subject":"git-bug: Distributed bug tracker embedded in git","startedAt":"2018-08-17T22:07:18Z","lastAt":"2018-08-19T21:08:04Z","messageCount":18,"participants":["Michael Muré","Tacitus Aedifex","Jonathan Nieder","Ævar Arnfjörð Bjarmason","Junio C Hamano","Elijah Newren","Kyle Meyer","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"355951","messageId":"CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=MutSsA@mail.gmail.com","threadId":"49156","inReplyTo":null,"subject":"git-bug: Distributed bug tracker embedded in git","fromName":"Michael Muré","fromEmail":"batolettre@gmail.com","sentAt":"2018-08-17T22:06:35Z","receivedAt":"2018-08-17T22:07:18Z","isPatch":false,"sender":{"key":"batolettre@gmail.com","avatar":null},"body":"Hi everyone,\n\nI released today git-bug, a distributed bug tracker that embeds in\ngit. It use git's internal storage to store bugs information in a way\nthat can be merged without conflict. You can push/pull to the normal\ngit remote you are already using to interact with other people. Normal\ncode and bugs are completely separated and no files are added in the\nregular branches.\n\nSomeone suggested in the Hacker News thread [0] to post it here as well.\n\nThe project is here [1].\n\nIt's a all-in-one binary that is picked up by git as a porcelain\ncommand. It features a set of CLI command for simple interaction, an\ninteractive terminal UI and a rich web UI.\n\nFor more information about the internal design, please read this\ndocument [2]. In short, bugs are stored as a series of edit operations\nstored in git blobs and assembled in a linear chain of commits. This\nallow to have conflict-free merge and to not pollute the regular\nbranches with bug data. Media embedding is also possible but not yet\nfinished.\n\nI'd love to have some feedback from you. Contribution are also very\nmuch welcomed.\n\nBest regards,\n\n[0]: https://news.ycombinator.com/item?id=17782121\n[1]: https://github.com/MichaelMure/git-bug\n[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md\n\n-- \nMichael Muré\n"},{"id":"355959","messageId":"20180817232024.GA25871@SDF.ORG","threadId":"49156","inReplyTo":"CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=MutSsA@mail.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Tacitus Aedifex","fromEmail":"aedifex@sdf.org","sentAt":"2018-08-17T23:20:24Z","receivedAt":"2018-08-17T23:20:44Z","isPatch":false,"sender":{"key":"aedifex@sdf.org","avatar":"https://gravatar.com/avatar/7d5361117c8a59b99af67c0282a2785183f7cee0f2a3294d8d3dcb7a6c00387d?d=mp&s=160"},"body":"I really like this idea. I've often wanted an integrated bug database like \nthis. My solution has always been to have a subrepo storing bug reports and \ncoments in .txt files and then using bash porcelain scripts to make a git-like \ninterface. I think I like this better. My only nit is Go. That makes me sad. \nSomeone should re-implement this in C or Rust.\n\n//tæ\n"},{"id":"355963","messageId":"20180818054300.GB241538@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=MutSsA@mail.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-18T05:43:00Z","receivedAt":"2018-08-18T05:43:58Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nMichael Muré wrote:\n\n> I released today git-bug, a distributed bug tracker that embeds in\n> git. It use git's internal storage to store bugs information in a way\n> that can be merged without conflict. You can push/pull to the normal\n> git remote you are already using to interact with other people. Normal\n> code and bugs are completely separated and no files are added in the\n> regular branches.\n\nI am a bit unhappy about the namespace grab. Not for trademark\nreasons: the Git trademark rules are pretty clear about this kind of\nusage being okay. Instead, the unhappiness comes because a future Git\ncommand like \"git bug\" to produce a bug report with appropriate\ndiagnostics for a bug in Git seems like a likely and useful thing to\nget added to Git some day. And now the name's taken.\n\nIs it too late to ask if it's possible to come up with a less generic\nname?\n\nSeparately from that, I'm happy to see progress being made in the\ndistributed bug tracker world; thanks for that!\n\nThanks,\nJonathan\n"},{"id":"355975","messageId":"874lfrrhfp.fsf@evledraar.gmail.com","threadId":"49156","inReplyTo":"20180818054300.GB241538@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-18T12:24:26Z","receivedAt":"2018-08-18T12:24:33Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 18 2018, Jonathan Nieder wrote:\n\n> Hi,\n>\n> Michael Muré wrote:\n>\n>> I released today git-bug, a distributed bug tracker that embeds in\n>> git. It use git's internal storage to store bugs information in a way\n>> that can be merged without conflict. You can push/pull to the normal\n>> git remote you are already using to interact with other people. Normal\n>> code and bugs are completely separated and no files are added in the\n>> regular branches.\n>\n> I am a bit unhappy about the namespace grab. Not for trademark\n> reasons: the Git trademark rules are pretty clear about this kind of\n> usage being okay. Instead, the unhappiness comes because a future Git\n> command like \"git bug\" to produce a bug report with appropriate\n> diagnostics for a bug in Git seems like a likely and useful thing to\n> get added to Git some day. And now the name's taken.\n>\n> Is it too late to ask if it's possible to come up with a less generic\n> name?\n\nWouldn't we call such a thing \"git-reportbug\", or \"git gitbug\", with\nreference to Debian reportbug or perl's perlbug?\n\nAddressing the more general issue, if we're concerned with 3rd party\ntools usurping the core namespace trying to convince individual authors\nof 3rd party tools to change the names of those tools to something more\nunique is pissing in the wind.\n\nThat's never going to make a dent in the vast amount of git-whatever\ntools, most of which won't be discussed as ideas on this mailing list\nbefore they're released.\n\nI think we basically have these options:\n\n1) Accept the status quo where people do create third party tools, much\n of which are way too obscure to matter (e.g. I'm sure someone's\n created a tool/alias called range-diff before, but we didn't\n care).\n\n If those tools become popular enough in the wild they get own that\n namespace, e.g. we're not going to ship a \"git-annex\" or \"git-lfs\"\n ourselves implementing some unrelated features (re parallel on-list\n discussion; \"git annex\" could also be a \"git commit --amend\" alias).\n\n2) #1, but hope we catch new tools early enough to convince their\n authors to change the names.\n\n3) Make some structural change to git where only things we ourselves\n compile get to be called as \"git \", and you'd need to call\n e.g. \"git-bug\" as \"git ext::bug\" or something. We'd need to have a\n large hardcoded list of older tools (lfs, annex, ...) to grandfather\n in if we went for this approach.\n\nI think we should just go for #1, and if we're concerned about #1 not\nbeing OK we really need something like #3, because #2 isn't going to\nwork.\n\n> Separately from that, I'm happy to see progress being made in the\n> distributed bug tracker world; thanks for that!\n>\n> Thanks,\n> Jonathan\n"},{"id":"356000","messageId":"xmqq6007abmu.fsf@gitster-ct.c.googlers.com","threadId":"49156","inReplyTo":"CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=MutSsA@mail.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-08-18T16:21:45Z","receivedAt":"2018-08-18T16:21:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Muré writes:\n\n> I released today git-bug, a distributed bug tracker that embeds in\n> git. It use git's internal storage to store bugs information in a way\n> that can be merged without conflict. You can push/pull to the normal\n> git remote you are already using to interact with other people. Normal\n> code and bugs are completely separated and no files are added in the\n> regular branches.\n\nThis reminds me of a demo Scott Chacon showed us ages ago, the name\nof which escapes me. I guess great minds think alike, or something?\n"},{"id":"356005","messageId":"20180818204243.GA136983@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"874lfrrhfp.fsf@evledraar.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-18T20:42:43Z","receivedAt":"2018-08-18T20:46:15Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nÆvar Arnfjörð Bjarmason wrote:\n> On Sat, Aug 18 2018, Jonathan Nieder wrote:\n>> Michael Muré wrote:\n\n>>> I released today git-bug, a distributed bug tracker\n[...]\n>> I am a bit unhappy about the namespace grab. Not for trademark\n>> reasons: the Git trademark rules are pretty clear about this kind of\n>> usage being okay. Instead, the unhappiness comes because a future Git\n>> command like \"git bug\" to produce a bug report with appropriate\n>> diagnostics for a bug in Git seems like a likely and useful thing to\n>> get added to Git some day. And now the name's taken.\n>>\n>> Is it too late to ask if it's possible to come up with a less generic\n>> name?\n>\n> Wouldn't we call such a thing \"git-reportbug\", or \"git gitbug\", with\n> reference to Debian reportbug or perl's perlbug?\n\nI hope you're kidding about \"git gitbug\".\n\n[...]\n> 1) Accept the status quo where people do create third party tools, much\n> of which are way too obscure to matter (e.g. I'm sure someone's\n> created a tool/alias called range-diff before, but we didn't\n> care).\n>\n> If those tools become popular enough in the wild they get own that\n> namespace, e.g. we're not going to ship a \"git-annex\" or \"git-lfs\"\n> ourselves implementing some unrelated features\n\nThat's fair. Let me spell out my thinking a little more.\n\nThis framework would lead me to rephrase my question to Michael a\ndifferent way. Instead of saying that I'm not happy with the\nnamespace grab, I should say something more severe:\n\n Don't be surprised if Git itself makes a \"git bug\" command in the\n future, and be prepared to rename.\n\nIs that preferable, in your opinion?\n\nI still think it's a reasonable thing for me to ask about, if only to\nsave Michael some trouble later.\n\nThanks,\nJonathan\n"},{"id":"356009","messageId":"8736vbqr2p.fsf@evledraar.gmail.com","threadId":"49156","inReplyTo":"20180818204243.GA136983@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-18T21:53:50Z","receivedAt":"2018-08-18T21:53:55Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 18 2018, Jonathan Nieder wrote:\n\n> Hi,\n>\n> Ævar Arnfjörð Bjarmason wrote:\n>> On Sat, Aug 18 2018, Jonathan Nieder wrote:\n>>> Michael Muré wrote:\n>\n>>>> I released today git-bug, a distributed bug tracker\n> [...]\n>>> I am a bit unhappy about the namespace grab. Not for trademark\n>>> reasons: the Git trademark rules are pretty clear about this kind of\n>>> usage being okay. Instead, the unhappiness comes because a future Git\n>>> command like \"git bug\" to produce a bug report with appropriate\n>>> diagnostics for a bug in Git seems like a likely and useful thing to\n>>> get added to Git some day. And now the name's taken.\n>>>\n>>> Is it too late to ask if it's possible to come up with a less generic\n>>> name?\n>>\n>> Wouldn't we call such a thing \"git-reportbug\", or \"git gitbug\", with\n>> reference to Debian reportbug or perl's perlbug?\n>\n> I hope you're kidding about \"git gitbug\".\n\nIt sounds a bit silly, but such a tool is going to be rarely used enough\nthat we probably don't want to squat a 3 letter command to invoke it.\n\n> [...]\n>> 1) Accept the status quo where people do create third party tools, much\n>> of which are way too obscure to matter (e.g. I'm sure someone's\n>> created a tool/alias called range-diff before, but we didn't\n>> care).\n>>\n>> If those tools become popular enough in the wild they get own that\n>> namespace, e.g. we're not going to ship a \"git-annex\" or \"git-lfs\"\n>> ourselves implementing some unrelated features\n>\n> That's fair. Let me spell out my thinking a little more.\n>\n> This framework would lead me to rephrase my question to Michael a\n> different way. Instead of saying that I'm not happy with the\n> namespace grab, I should say something more severe:\n>\n> Don't be surprised if Git itself makes a \"git bug\" command in the\n> future, and be prepared to rename.\n>\n> Is that preferable, in your opinion?\n\nWe're not going to make some blanket policy that doesn't recognize the\ndifference between say git-lfs and git-tool_nobody_has_ever_heard_of,\nand then decide that it would be just as reasonable for us to ship a new\ngit-lfs ourselves (which would do something different) as it were for us\nto ship git-tool_nobody_has_ever_heard_of.\n\nThe reason I can drop a \"git-whatever\" in my $PATH and invoke it as \"git\nwhatever\" is just a historical accident of how git was implemented.\n\nBut because that feature has been exposed since the very beginning it's\nbecome an implicit API. There's thousands of git-whatever tools, and\npeople do use these. The likes of git-lfs and git-annex are used a *lot*\nmore than some builtins we ship.\n\nSo we don't get to say \"you never asked us about git-annex, we're using\nthat name now\" without considering how widely used it is. It's us who\ndecided to expose the API of seamlessly integrating 3rd party tools.\n"},{"id":"356012","messageId":"20180818220821.GC144170@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"8736vbqr2p.fsf@evledraar.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-18T22:08:21Z","receivedAt":"2018-08-18T22:08:26Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n\n> The reason I can drop a \"git-whatever\" in my $PATH and invoke it as \"git\n> whatever\" is just a historical accident of how git was implemented.\n\nNo. This is a very deliberate design decision, to allow people to\nprototype new Git commands (and to create the kind of ecosystem that\nallows commands to be implemented outside Git.\n\n[...]\n> So we don't get to say \"you never asked us about git-annex, we're using\n> that name now\" without considering how widely used it is. It's us who\n> decided to expose the API of seamlessly integrating 3rd party tools.\n\nI think we're talking past each other. I haven't proposed any blanket\npolicy. I'm saying that \"git bug\" is a bad name for this tool:\n\n - it's hard to find with search engines\n - it conflicts with some likely good future changes to Git\n - it assumes that no one else will have some other refinement of the\n Git bugtracker concept, that it is the only \"git bug\" tool\n\nIt's a namespace grab. There's nothing stopping someone from naming a\ncommand \"bug\", either, but that doesn't make it a good idea. (I'm not\nsaying that was the intent --- that's just the effect.)\n\nMeanwhile it looks like a neat tool, and I'm very supportive of the\nidea. But you certainly still have not convinced me that the name is\na good idea, or that I shouldn't be bringing this up.\n\nI'm not sure *what* you're trying to convince me of, actually.\n\nJonathan\n"},{"id":"356014","messageId":"871savqpvo.fsf@evledraar.gmail.com","threadId":"49156","inReplyTo":"20180818220821.GC144170@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-18T22:19:39Z","receivedAt":"2018-08-18T22:25:26Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Aug 18 2018, Jonathan Nieder wrote:\n\n> Ævar Arnfjörð Bjarmason wrote:\n>\n>> The reason I can drop a \"git-whatever\" in my $PATH and invoke it as \"git\n>> whatever\" is just a historical accident of how git was implemented.\n>\n> No. This is a very deliberate design decision, to allow people to\n> prototype new Git commands (and to create the kind of ecosystem that\n> allows commands to be implemented outside Git.\n>\n> [...]\n>> So we don't get to say \"you never asked us about git-annex, we're using\n>> that name now\" without considering how widely used it is. It's us who\n>> decided to expose the API of seamlessly integrating 3rd party tools.\n>\n> I think we're talking past each other. I haven't proposed any blanket\n> policy. I'm saying that \"git bug\" is a bad name for this tool:\n>\n> - it's hard to find with search engines\n> - it conflicts with some likely good future changes to Git\n> - it assumes that no one else will have some other refinement of the\n> Git bugtracker concept, that it is the only \"git bug\" tool\n>\n> It's a namespace grab. There's nothing stopping someone from naming a\n> command \"bug\", either, but that doesn't make it a good idea. (I'm not\n> saying that was the intent --- that's just the effect.)\n>\n> Meanwhile it looks like a neat tool, and I'm very supportive of the\n> idea. But you certainly still have not convinced me that the name is\n> a good idea, or that I shouldn't be bringing this up.\n>\n> I'm not sure *what* you're trying to convince me of, actually.\n\nI'm not saying the git-bug name is a good idea, or that it isn't. I\ndon't care about this particular case when it comes to naming.\n\nI'm just pointing out in the more general case that if someone comes up\nwith a badly named git-xyz it doesn't scale to try to point this out to\nthem before git-xyz is widely deployed.\n\nSo we must either let it go (solution #1), or come up with some\nAPI-level solution that makes it a non-issue (my #3).\n"},{"id":"356015","messageId":"20180818222654.GD144170@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"871savqpvo.fsf@evledraar.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-18T22:26:54Z","receivedAt":"2018-08-18T22:26:59Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n\n> I'm just pointing out in the more general case that if someone comes up\n> with a badly named git-xyz it doesn't scale to try to point this out to\n> them before git-xyz is widely deployed.\n>\n> So we must either let it go (solution #1), or come up with some\n> API-level solution that makes it a non-issue (my #3).\n\nHow about solution #4: live and let live when it comes down to it, but\nact like actual people and talk to avoid negative consequences?\n\nSome social problems don't have technical solutions.\n\nTalking scales, in strange ways. For example, people are able to look\nat the list archive, people are able to spread thoughts they have\nfound interesting, and so on.\n\nJonathan\n"},{"id":"356017","messageId":"20180818225052.GE144170@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"CACSZ0Pwzs2e7E5RUEPDcEUsa=inzCyBAptU7YaCUw+5=MutSsA@mail.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-18T22:50:52Z","receivedAt":"2018-08-18T22:50:57Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(cc-ing Elijah Newren for the points about merging)\nHi again,\n\nTo avoid the other thread shadowing more important things:\n\nMichael Muré wrote:\n\n> Someone suggested in the Hacker News thread [0] to post it here as well.\n\nThanks to Ævar for that.\n\n[...]\n> git-bug use as identifier the hash of the first commit in the chain\n> of commit of the bug.\n\nClever! I like this approach to the naming problem.\n\n[...]\n> Git doesn't provide a low-level command to rebase a branch onto\n> another without touching the index.\n\nThanks for pointing this out. There's been some recent work to make\nGit's merge code (also used for cherry-pick) less reliant on the index\nand worktree. See https://crbug.com/git/12 for some references.\nThere's also been some heavy refactoring of \"git rebase\" code to be in\nC and be able to make use of library functions instead of being a\nshell script.\n\nThat's all to say that we're in a pretty good place to consider\nintroducing commands like\n\n git cherry-pick --onto= \n\nIn absence of that kind of thing, you can run commands that need to\ntouch the index (but not the working tree) by setting the GIT_INDEX\nenvironment variable to point to a temporary index file.\n\n> I'd love to have some feedback from you. Contribution are also very\n> much welcomed.\n\nCan you say more about the federation model it intends to support?\nFor example, do you imagine\n\n- having multiple copies of a git bugs repo that automatically fetch\n updates from each other\n\n- having explicit \"pull request\" synchronization moments when the\n owners of one copy of a bug tracker push or request a fetch of\n changes that have been happening on another\n\n- individual contributors using an offline copy of the bug tracker\n and pushing push/pull mostly to synchronize with a single\n centralized copy\n\n- something else?\n\nThanks,\nJonathan\n"},{"id":"356019","messageId":"CACSZ0PzcvYNtZEHqWCrU-5+hT=YeJ4DHpJ0j83QYn1qVEs5fjg@mail.gmail.com","threadId":"49156","inReplyTo":"20180818225052.GE144170@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Michael Muré","fromEmail":"batolettre@gmail.com","sentAt":"2018-08-19T00:45:05Z","receivedAt":"2018-08-19T00:45:48Z","isPatch":false,"sender":{"key":"batolettre@gmail.com","avatar":null},"body":"Here was my reasoning for the naming choice:\n\n- I need something meaningful\n- I need something that encompass the idea and features of a bug\ntracker because the narrower ideas and actions will be in sub commands\n- other projects already used other words, in particular \"issue\"\n- it kind of sounds and looks good\n\nYou say that it's a namespace grab and I understand that, but in the\nother hand, there is not that much freedom when choosing a name. Sorry\nif I'm stepping on someone's toe :-|\n\n2018-08-19 0:50 GMT+02:00 Jonathan Nieder :\n> (cc-ing Elijah Newren for the points about merging)\n> Hi again,\n>\n> To avoid the other thread shadowing more important things:\n>\n> Michael Muré wrote:\n>\n>> Someone suggested in the Hacker News thread [0] to post it here as well.\n>\n> Thanks to Ævar for that.\n>\n> [...]\n>> git-bug use as identifier the hash of the first commit in the chain\n>> of commit of the bug.\n>\n> Clever! I like this approach to the naming problem.\n>\n> [...]\n>> Git doesn't provide a low-level command to rebase a branch onto\n>> another without touching the index.\n>\n> Thanks for pointing this out. There's been some recent work to make\n> Git's merge code (also used for cherry-pick) less reliant on the index\n> and worktree. See https://crbug.com/git/12 for some references.\n> There's also been some heavy refactoring of \"git rebase\" code to be in\n> C and be able to make use of library functions instead of being a\n> shell script.\n>\n> That's all to say that we're in a pretty good place to consider\n> introducing commands like\n>\n> git cherry-pick --onto= \n>\n> In absence of that kind of thing, you can run commands that need to\n> touch the index (but not the working tree) by setting the GIT_INDEX\n> environment variable to point to a temporary index file.\n>\n>> I'd love to have some feedback from you. Contribution are also very\n>> much welcomed.\n>\n> Can you say more about the federation model it intends to support?\n> For example, do you imagine\n>\n> - having multiple copies of a git bugs repo that automatically fetch\n> updates from each other\n>\n> - having explicit \"pull request\" synchronization moments when the\n> owners of one copy of a bug tracker push or request a fetch of\n> changes that have been happening on another\n>\n> - individual contributors using an offline copy of the bug tracker\n> and pushing push/pull mostly to synchronize with a single\n> centralized copy\n>\n> - something else?\n>\n> Thanks,\n> Jonathan\n\n\n\n-- \nMichael\n"},{"id":"356020","messageId":"CACSZ0PyfOV4o8k+H-OSjVSYGHgy=v=4q2S-x7NABxQNY9976Ug@mail.gmail.com","threadId":"49156","inReplyTo":"CACSZ0PzcvYNtZEHqWCrU-5+hT=YeJ4DHpJ0j83QYn1qVEs5fjg@mail.gmail.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Michael Muré","fromEmail":"batolettre@gmail.com","sentAt":"2018-08-19T01:14:40Z","receivedAt":"2018-08-19T01:15:23Z","isPatch":false,"sender":{"key":"batolettre@gmail.com","avatar":null},"body":"> There's been some recent work to make\n> Git's merge code (also used for cherry-pick) less reliant on the index\n> and worktree.\n\nYes please ! In the mean time, someone suggested another trick [0].\n\n> Can you say more about the federation model it intends to support?\n\nMy goal is to have a workflow similar as what git does, to be\nversatile and leave to the users the choice of the topology they want\nto use. Obviously, it will be most of the time a single remote where\nthey collaborate.\n\nAs a bug tracker is a different workflow than regular code, there will\nbe some tooling to help. For instance, automatic push/pull will help\nmake it easier to use and more \"out of the way\".\n\nIn the data model, each commit in the linear chain link to an array of\nnew edit operations. That means that each commit is strictly\nindependent from the others. When you get updates for a bug and you\nneed to merge them, you will simply rebase your new commits on top of\nthe linear chain.\n\nThis design has several properties:\n\n- the merge happen on the user repo where git-bug is installed and can\nvalidate new data\n- the remote used doesn't have to be aware of git-bug\n- when pushing an update of a ref, the remote will make sure that it's\nfast forward, that is, no previous edit operations has been removed.\nIt ensure that the history is append only.\n\nSo for now, collaboration is based on push/pull to whatever remote you\nwant, as git does, with the exception of the Web UI. The goal here is\nto have it running locally for each user but also to make it a public\ninterface for users that don't have write access to the repo, much\nlike any bug tracker has.\n\nIn the future, it could be possible to have more fancy features like a\nfederated forge with ActivityPub, but that's way outside of the scope\nof the project for now.\n\n[0]: https://github.com/MichaelMure/git-bug/issues/15\n\n2018-08-19 2:45 GMT+02:00 Michael Muré :\n> Here was my reasoning for the naming choice:\n>\n> - I need something meaningful\n> - I need something that encompass the idea and features of a bug\n> tracker because the narrower ideas and actions will be in sub commands\n> - other projects already used other words, in particular \"issue\"\n> - it kind of sounds and looks good\n>\n> You say that it's a namespace grab and I understand that, but in the\n> other hand, there is not that much freedom when choosing a name. Sorry\n> if I'm stepping on someone's toe :-|\n>\n> 2018-08-19 0:50 GMT+02:00 Jonathan Nieder :\n>> (cc-ing Elijah Newren for the points about merging)\n>> Hi again,\n>>\n>> To avoid the other thread shadowing more important things:\n>>\n>> Michael Muré wrote:\n>>\n>>> Someone suggested in the Hacker News thread [0] to post it here as well.\n>>\n>> Thanks to Ævar for that.\n>>\n>> [...]\n>>> git-bug use as identifier the hash of the first commit in the chain\n>>> of commit of the bug.\n>>\n>> Clever! I like this approach to the naming problem.\n>>\n>> [...]\n>>> Git doesn't provide a low-level command to rebase a branch onto\n>>> another without touching the index.\n>>\n>> Thanks for pointing this out. There's been some recent work to make\n>> Git's merge code (also used for cherry-pick) less reliant on the index\n>> and worktree. See https://crbug.com/git/12 for some references.\n>> There's also been some heavy refactoring of \"git rebase\" code to be in\n>> C and be able to make use of library functions instead of being a\n>> shell script.\n>>\n>> That's all to say that we're in a pretty good place to consider\n>> introducing commands like\n>>\n>> git cherry-pick --onto= \n>>\n>> In absence of that kind of thing, you can run commands that need to\n>> touch the index (but not the working tree) by setting the GIT_INDEX\n>> environment variable to point to a temporary index file.\n>>\n>>> I'd love to have some feedback from you. Contribution are also very\n>>> much welcomed.\n>>\n>> Can you say more about the federation model it intends to support?\n>> For example, do you imagine\n>>\n>> - having multiple copies of a git bugs repo that automatically fetch\n>> updates from each other\n>>\n>> - having explicit \"pull request\" synchronization moments when the\n>> owners of one copy of a bug tracker push or request a fetch of\n>> changes that have been happening on another\n>>\n>> - individual contributors using an offline copy of the bug tracker\n>> and pushing push/pull mostly to synchronize with a single\n>> centralized copy\n>>\n>> - something else?\n>>\n>> Thanks,\n>> Jonathan\n>\n>\n>\n> --\n> Michael\n\n\n\n-- \nMichael\n"},{"id":"356021","messageId":"20180819012748.GA175033@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"xmqq6007abmu.fsf@gitster-ct.c.googlers.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-19T01:27:48Z","receivedAt":"2018-08-19T01:27:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(cc-ing Scott)\nHi Junio,\n\nJunio C Hamano wrote:\n> Michael Muré writes:\n\n>> I released today git-bug, a distributed bug tracker that embeds in\n>> git. It use git's internal storage to store bugs information in a way\n>> that can be merged without conflict. You can push/pull to the normal\n>> git remote you are already using to interact with other people. Normal\n>> code and bugs are completely separated and no files are added in the\n>> regular branches.\n>\n> This reminds me of a demo Scott Chacon showed us ages ago, the name\n> of which escapes me. I guess great minds think alike, or something?\n\nI believe you're thinking of TicGit[1].\n\nSome other related work is listed at [2]. Most of these projects have\ngone quiet:\n\n- ditz[3]\n- git-issues[4]\n- cil[5]\n- Bugs Everywhere[6]\n- milli by Steve Kemp, which I haven't found a copy of\n- simple defects[7]\n- kipling[8]\n\nhttp://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ gives a\nnice overview, though it's rather old.\n\nThis area seems to have gone mostly quiet since 2014, so it's nice to\nsee new work.\n\nThanks,\nJonathan\n\n[1] https://github.com/jeffWelling/ticgit\n[2] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc.\n[3] https://github.com/jashmenn/ditz\n[4] https://github.com/duplys/git-issues\n[5] https://github.com/chilts/cil\n[6] http://bugseverywhere.org/\n[7] https://syncwith.us/sd/, https://gitorious.org/prophet/sd\n[8] https://gitorious.org/kipling/mainline\n"},{"id":"356023","messageId":"CABPp-BE+zfWOqQQoO0mvJPefODW3fDsfYuC6OzBzSD5fe1xarg@mail.gmail.com","threadId":"49156","inReplyTo":"20180818225052.GE144170@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2018-08-19T02:06:16Z","receivedAt":"2018-08-19T02:06:35Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sat, Aug 18, 2018 at 3:50 PM Jonathan Nieder wrote:\n> (cc-ing Elijah Newren for the points about merging)\n\n> [...]\n> > Git doesn't provide a low-level command to rebase a branch onto\n> > another without touching the index.\n>\n> Thanks for pointing this out. There's been some recent work to make\n> Git's merge code (also used for cherry-pick) less reliant on the index\n> and worktree. See https://crbug.com/git/12 for some references.\n> There's also been some heavy refactoring of \"git rebase\" code to be in\n> C and be able to make use of library functions instead of being a\n> shell script.\n>\n> That's all to say that we're in a pretty good place to consider\n> introducing commands like\n>\n> git cherry-pick --onto= \n\nYes, indeed, after the merge refactoring/rewriting stuff is complete,\nthis is one thing already on my list that I wanted to do with it.\nAnother thing I'd like to investigate with it is how much \"in-memory\"\nmerges could speed up interactive rebases, as suggested by Dscho[1].\nOnce we do \"in-memory\" merges for interactive rebases for performance\nreasons, we're pretty close to having a\nrebase-without-touching-index-or-worktree that we can make accessible\nto other scripts like git-bug. However, we have to have a pretty good\nanswer about what to do when we hit conflicts.\n\n[1] https://public-inbox.org/git/nycvar.QRO.7.76.6.1806100006000.77@tvgsbejvaqbjf.bet/\n"},{"id":"356025","messageId":"87y3d3m2e4.fsf@kyleam.com","threadId":"49156","inReplyTo":"20180819012748.GA175033@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Kyle Meyer","fromEmail":"kyle@kyleam.com","sentAt":"2018-08-19T04:00:35Z","receivedAt":"2018-08-19T04:01:42Z","isPatch":false,"sender":{"key":"kyle@kyleam.com","avatar":"https://avatars.githubusercontent.com/u/1297788?v=4"},"body":"[+cc Stefan Monnier]\n\nJonathan Nieder writes:\n\n> (cc-ing Scott)\n\n[...]\n\n> I believe you're thinking of TicGit[1].\n>\n> Some other related work is listed at [2]. Most of these projects have\n> gone quiet:\n>\n> - ditz[3]\n> - git-issues[4]\n> - cil[5]\n> - Bugs Everywhere[6]\n> - milli by Steve Kemp, which I haven't found a copy of\n> - simple defects[7]\n> - kipling[8]\n\nTo add to that list: There's also BuGit [1,2], though it too seems to\nhave gone quiet.\n\n[1]: https://gitlab.com/monnier/bugit\n[2]: https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control.git@gnu.org/\n\n\n-- \nKyle\n"},{"id":"356027","messageId":"20180819050147.GA207351@aiede.svl.corp.google.com","threadId":"49156","inReplyTo":"87y3d3m2e4.fsf@kyleam.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-08-19T05:01:47Z","receivedAt":"2018-08-19T05:01:53Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"(+ git-dit authors)\nKyle Meyer wrote:\n> Jonathan Nieder writes:\n\n>> I believe you're thinking of TicGit[1].\n>>\n>> Some other related work is listed at [2]. Most of these projects have\n>> gone quiet:\n>>\n>> - ditz[3]\n>> - git-issues[4]\n>> - cil[5]\n>> - Bugs Everywhere[6]\n>> - milli by Steve Kemp, which I haven't found a copy of\n>> - simple defects[7]\n>> - kipling[8]\n>\n> To add to that list: There's also BuGit [1,2], though it too seems to\n> have gone quiet.\n\nI just found a good list on a non Git-specific wiki[3] that is more\nhelpful (more up to date and has more discussion) than the list on the\nGit wiki.\n\nIt might be a good place to coordinate and compare notes. git-dit[4]\nin particular seems to have very similar goals and a similar data\nmodel. In my ideal world there may be a path forward that involves\nworking more closely together.\n\nThanks,\nJonathan\n\n> [1]: https://gitlab.com/monnier/bugit\n> [2]: https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control.git@gnu.org/\n[3] https://dist-bugs.branchable.com/software/\n[4] https://github.com/neithernut/git-dit\n"},{"id":"356056","messageId":"20180819210800.GA17277@sigill.intra.peff.net","threadId":"49156","inReplyTo":"20180818220821.GC144170@aiede.svl.corp.google.com","subject":"Re: git-bug: Distributed bug tracker embedded in git","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-08-19T21:08:00Z","receivedAt":"2018-08-19T21:08:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 18, 2018 at 03:08:21PM -0700, Jonathan Nieder wrote:\n\n> > So we don't get to say \"you never asked us about git-annex, we're using\n> > that name now\" without considering how widely used it is. It's us who\n> > decided to expose the API of seamlessly integrating 3rd party tools.\n> \n> I think we're talking past each other. I haven't proposed any blanket\n> policy. I'm saying that \"git bug\" is a bad name for this tool:\n> \n> - it's hard to find with search engines\n> - it conflicts with some likely good future changes to Git\n> - it assumes that no one else will have some other refinement of the\n> Git bugtracker concept, that it is the only \"git bug\" tool\n> \n> It's a namespace grab. There's nothing stopping someone from naming a\n> command \"bug\", either, but that doesn't make it a good idea. (I'm not\n> saying that was the intent --- that's just the effect.)\n\nRight, I think this is a sensible way to think about it. When the time\ncomes later to call something \"git bug\", obviously we'd consider the\noverall ecosystem and weigh that. But that does not make it a good idea\nto pick a name that is likely to get stomped on.\n\nAnd the most we can do is recommend against it and let them make the\ndecision. The Microsoft GVFS folks are in a similar situation. They are\nrenaming the project and thinking about using git-vfs for the command\nname. IMHO that is too generic, and I've mentioned that, but ultimately\nI think it is their choice.\n\n-Peff\n"}]}