Re: git-bug: Distributed bug tracker embedded in git
On Sat, Aug 18, 2018 at 03:08:21PM -0700, Jonathan Nieder wrote: > > 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.) Right, I think this is a sensible way to think about it. When the time comes later to call something "git bug", obviously we'd consider the overall ecosystem and weigh that. But that does not make it a good idea to pick a name that is likely to get stomped on. And the most we can do is recommend against it and let them make the decision. The Microsoft GVFS folks are in a similar situation. They are renaming the project and thinking about using git-vfs for the command name. IMHO that is too generic, and I've mentioned that, but ultimately I think it is their choice. -Peff
Re: git-bug: Distributed bug tracker embedded in git
(+ git-dit authors) Kyle Meyer wrote: > Jonathan Nieder writes: >> I believe you're thinking of TicGit[1]. >> >> Some other related work is listed at [2]. Most of these projects have >> gone quiet: >> >> - ditz[3] >> - git-issues[4] >> - cil[5] >> - Bugs Everywhere[6] >> - milli by Steve Kemp, which I haven't found a copy of >> - simple defects[7] >> - kipling[8] > > To add to that list: There's also BuGit [1,2], though it too seems to > have gone quiet. I just found a good list on a non Git-specific wiki[3] that is more helpful (more up to date and has more discussion) than the list on the Git wiki. It might be a good place to coordinate and compare notes. git-dit[4] in particular seems to have very similar goals and a similar data model. In my ideal world there may be a path forward that involves working more closely together. Thanks, Jonathan > [1]: https://gitlab.com/monnier/bugit > [2]: > https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control@gnu.org/ [3] https://dist-bugs.branchable.com/software/ [4] https://github.com/neithernut/git-dit
Re: git-bug: Distributed bug tracker embedded in git
[+cc Stefan Monnier] Jonathan Nieder writes: > (cc-ing Scott) [...] > I believe you're thinking of TicGit[1]. > > Some other related work is listed at [2]. Most of these projects have > gone quiet: > > - ditz[3] > - git-issues[4] > - cil[5] > - Bugs Everywhere[6] > - milli by Steve Kemp, which I haven't found a copy of > - simple defects[7] > - kipling[8] To add to that list: There's also BuGit [1,2], though it too seems to have gone quiet. [1]: https://gitlab.com/monnier/bugit [2]: https://public-inbox.org/git/jwva8psr6vr.fsf-monnier+gmane.comp.version-control@gnu.org/ -- Kyle
Re: git-bug: Distributed bug tracker embedded in git
On Sat, Aug 18, 2018 at 3:50 PM Jonathan Nieder wrote: > (cc-ing Elijah Newren for the points about merging) > [...] > > Git doesn't provide a low-level command to rebase a branch onto > > another without touching the index. > > Thanks for pointing this out. There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. See https://crbug.com/git/12 for some references. > There's also been some heavy refactoring of "git rebase" code to be in > C and be able to make use of library functions instead of being a > shell script. > > That's all to say that we're in a pretty good place to consider > introducing commands like > > git cherry-pick --onto= Yes, indeed, after the merge refactoring/rewriting stuff is complete, this is one thing already on my list that I wanted to do with it. Another thing I'd like to investigate with it is how much "in-memory" merges could speed up interactive rebases, as suggested by Dscho[1]. Once we do "in-memory" merges for interactive rebases for performance reasons, we're pretty close to having a rebase-without-touching-index-or-worktree that we can make accessible to other scripts like git-bug. However, we have to have a pretty good answer about what to do when we hit conflicts. [1] https://public-inbox.org/git/nycvar.qro.7.76.6.180616000...@tvgsbejvaqbjf.bet/
Re: git-bug: Distributed bug tracker embedded in git
(cc-ing Scott) Hi Junio, Junio C Hamano wrote: > Michael Muré writes: >> 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. > > This reminds me of a demo Scott Chacon showed us ages ago, the name > of which escapes me. I guess great minds think alike, or something? I believe you're thinking of TicGit[1]. Some other related work is listed at [2]. Most of these projects have gone quiet: - ditz[3] - git-issues[4] - cil[5] - Bugs Everywhere[6] - milli by Steve Kemp, which I haven't found a copy of - simple defects[7] - kipling[8] http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ gives a nice overview, though it's rather old. This area seems to have gone mostly quiet since 2014, so it's nice to see new work. Thanks, Jonathan [1] https://github.com/jeffWelling/ticgit [2] https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Bug.2Fissue_trackers.2C_etc. [3] https://github.com/jashmenn/ditz [4] https://github.com/duplys/git-issues [5] https://github.com/chilts/cil [6] http://bugseverywhere.org/ [7] https://syncwith.us/sd/, https://gitorious.org/prophet/sd [8] https://gitorious.org/kipling/mainline
Re: git-bug: Distributed bug tracker embedded in git
> There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. Yes please ! In the mean time, someone suggested another trick [0]. > Can you say more about the federation model it intends to support? My goal is to have a workflow similar as what git does, to be versatile and leave to the users the choice of the topology they want to use. Obviously, it will be most of the time a single remote where they collaborate. As a bug tracker is a different workflow than regular code, there will be some tooling to help. For instance, automatic push/pull will help make it easier to use and more "out of the way". In the data model, each commit in the linear chain link to an array of new edit operations. That means that each commit is strictly independent from the others. When you get updates for a bug and you need to merge them, you will simply rebase your new commits on top of the linear chain. This design has several properties: - the merge happen on the user repo where git-bug is installed and can validate new data - the remote used doesn't have to be aware of git-bug - when pushing an update of a ref, the remote will make sure that it's fast forward, that is, no previous edit operations has been removed. It ensure that the history is append only. So for now, collaboration is based on push/pull to whatever remote you want, as git does, with the exception of the Web UI. The goal here is to have it running locally for each user but also to make it a public interface for users that don't have write access to the repo, much like any bug tracker has. In the future, it could be possible to have more fancy features like a federated forge with ActivityPub, but that's way outside of the scope of the project for now. [0]: https://github.com/MichaelMure/git-bug/issues/15 2018-08-19 2:45 GMT+02:00 Michael Muré : > Here was my reasoning for the naming choice: > > - I need something meaningful > - I need something that encompass the idea and features of a bug > tracker because the narrower ideas and actions will be in sub commands > - other projects already used other words, in particular "issue" > - it kind of sounds and looks good > > You say that it's a namespace grab and I understand that, but in the > other hand, there is not that much freedom when choosing a name. Sorry > if I'm stepping on someone's toe :-| > > 2018-08-19 0:50 GMT+02:00 Jonathan Nieder : >> (cc-ing Elijah Newren for the points about merging) >> Hi again, >> >> To avoid the other thread shadowing more important things: >> >> Michael Muré wrote: >> >>> Someone suggested in the Hacker News thread [0] to post it here as well. >> >> Thanks to Ævar for that. >> >> [...] >>> git-bug use as identifier the hash of the first commit in the chain >>> of commit of the bug. >> >> Clever! I like this approach to the naming problem. >> >> [...] >>> Git doesn't provide a low-level command to rebase a branch onto >>> another without touching the index. >> >> Thanks for pointing this out. There's been some recent work to make >> Git's merge code (also used for cherry-pick) less reliant on the index >> and worktree. See https://crbug.com/git/12 for some references. >> There's also been some heavy refactoring of "git rebase" code to be in >> C and be able to make use of library functions instead of being a >> shell script. >> >> That's all to say that we're in a pretty good place to consider >> introducing commands like >> >> git cherry-pick --onto= >> >> In absence of that kind of thing, you can run commands that need to >> touch the index (but not the working tree) by setting the GIT_INDEX >> environment variable to point to a temporary index file. >> >>> I'd love to have some feedback from you. Contribution are also very >>> much welcomed. >> >> Can you say more about the federation model it intends to support? >> For example, do you imagine >> >> - having multiple copies of a git bugs repo that automatically fetch >> updates from each other >> >> - having explicit "pull request" synchronization moments when the >> owners of one copy of a bug tracker push or request a fetch of >> changes that have been happening on another >> >> - individual contributors using an offline copy of the bug tracker >> and pushing push/pull mostly to synchronize with a single >> centralized copy >> >> - something else? >> >> Thanks, >> Jonathan > > > > -- > Michael -- Michael
Re: git-bug: Distributed bug tracker embedded in git
Here was my reasoning for the naming choice: - I need something meaningful - I need something that encompass the idea and features of a bug tracker because the narrower ideas and actions will be in sub commands - other projects already used other words, in particular "issue" - it kind of sounds and looks good You say that it's a namespace grab and I understand that, but in the other hand, there is not that much freedom when choosing a name. Sorry if I'm stepping on someone's toe :-| 2018-08-19 0:50 GMT+02:00 Jonathan Nieder : > (cc-ing Elijah Newren for the points about merging) > Hi again, > > To avoid the other thread shadowing more important things: > > Michael Muré wrote: > >> Someone suggested in the Hacker News thread [0] to post it here as well. > > Thanks to Ævar for that. > > [...] >> git-bug use as identifier the hash of the first commit in the chain >> of commit of the bug. > > Clever! I like this approach to the naming problem. > > [...] >> Git doesn't provide a low-level command to rebase a branch onto >> another without touching the index. > > Thanks for pointing this out. There's been some recent work to make > Git's merge code (also used for cherry-pick) less reliant on the index > and worktree. See https://crbug.com/git/12 for some references. > There's also been some heavy refactoring of "git rebase" code to be in > C and be able to make use of library functions instead of being a > shell script. > > That's all to say that we're in a pretty good place to consider > introducing commands like > > git cherry-pick --onto= > > In absence of that kind of thing, you can run commands that need to > touch the index (but not the working tree) by setting the GIT_INDEX > environment variable to point to a temporary index file. > >> I'd love to have some feedback from you. Contribution are also very >> much welcomed. > > Can you say more about the federation model it intends to support? > For example, do you imagine > > - having multiple copies of a git bugs repo that automatically fetch > updates from each other > > - having explicit "pull request" synchronization moments when the > owners of one copy of a bug tracker push or request a fetch of > changes that have been happening on another > > - individual contributors using an offline copy of the bug tracker > and pushing push/pull mostly to synchronize with a single > centralized copy > > - something else? > > Thanks, > Jonathan -- Michael
Re: git-bug: Distributed bug tracker embedded in git
(cc-ing Elijah Newren for the points about merging) Hi again, To avoid the other thread shadowing more important things: Michael Muré wrote: > Someone suggested in the Hacker News thread [0] to post it here as well. Thanks to Ævar for that. [...] > git-bug use as identifier the hash of the first commit in the chain > of commit of the bug. Clever! I like this approach to the naming problem. [...] > Git doesn't provide a low-level command to rebase a branch onto > another without touching the index. Thanks for pointing this out. There's been some recent work to make Git's merge code (also used for cherry-pick) less reliant on the index and worktree. See https://crbug.com/git/12 for some references. There's also been some heavy refactoring of "git rebase" code to be in C and be able to make use of library functions instead of being a shell script. That's all to say that we're in a pretty good place to consider introducing commands like git cherry-pick --onto= In absence of that kind of thing, you can run commands that need to touch the index (but not the working tree) by setting the GIT_INDEX environment variable to point to a temporary index file. > I'd love to have some feedback from you. Contribution are also very > much welcomed. Can you say more about the federation model it intends to support? For example, do you imagine - having multiple copies of a git bugs repo that automatically fetch updates from each other - having explicit "pull request" synchronization moments when the owners of one copy of a bug tracker push or request a fetch of changes that have been happening on another - individual contributors using an offline copy of the bug tracker and pushing push/pull mostly to synchronize with a single centralized copy - something else? Thanks, Jonathan
Re: git-bug: Distributed bug tracker embedded in git
Ævar Arnfjörð Bjarmason wrote: > 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). How about solution #4: live and let live when it comes down to it, but act like actual people and talk to avoid negative consequences? Some social problems don't have technical solutions. Talking scales, in strange ways. For example, people are able to look at the list archive, people are able to spread thoughts they have found interesting, and so on. Jonathan
Re: git-bug: Distributed bug tracker embedded in git
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).
Re: git-bug: Distributed bug tracker embedded in git
Æ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. Jonathan
Re: git-bug: Distributed bug tracker embedded in git
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.
Re: git-bug: Distributed bug tracker embedded in git
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". [...] > 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? I still think it's a reasonable thing for me to ask about, if only to save Michael some trouble later. Thanks, Jonathan
Re: git-bug: Distributed bug tracker embedded in git
Michael Muré writes: > 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. This reminds me of a demo Scott Chacon showed us ages ago, the name of which escapes me. I guess great minds think alike, or something?
Re: git-bug: Distributed bug tracker embedded in git
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 ", 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
Re: git-bug: Distributed bug tracker embedded in git
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? Separately from that, I'm happy to see progress being made in the distributed bug tracker world; thanks for that! Thanks, Jonathan
Re: git-bug: Distributed bug tracker embedded in git
I really like this idea. I've often wanted an integrated bug database like this. My solution has always been to have a subrepo storing bug reports and coments in .txt files and then using bash porcelain scripts to make a git-like interface. I think I like this better. My only nit is Go. That makes me sad. Someone should re-implement this in C or Rust. //t??
git-bug: Distributed bug tracker embedded in git
Hi everyone, 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. Someone suggested in the Hacker News thread [0] to post it here as well. The project is here [1]. It's a all-in-one binary that is picked up by git as a porcelain command. It features a set of CLI command for simple interaction, an interactive terminal UI and a rich web UI. For more information about the internal design, please read this document [2]. In short, bugs are stored as a series of edit operations stored in git blobs and assembled in a linear chain of commits. This allow to have conflict-free merge and to not pollute the regular branches with bug data. Media embedding is also possible but not yet finished. I'd love to have some feedback from you. Contribution are also very much welcomed. Best regards, [0]: https://news.ycombinator.com/item?id=17782121 [1]: https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md -- Michael Muré
