I noticed the OT based approach for the Data Model for a BUG. Wondering if you think this is better thanthe CRDT approach ?
But anyway i was thinking about how lots of users have to fork and then manage setting up the brnahc and then doing a PR. It can be tricky for new golang users. SO i want to suggest that this be incorporated later. I saw a repo in golang just the other day that did this.
anyway, hope to hear your thoughts. The code base looks really clean and easy to follow and i want to congratulate you on this excellent work.
In terms of a github server, do you envisage users using gitea or other ?
Damn, how come people find this repo when I didn't advertise it ?
I noticed the OT based approach for the Data Model for a BUG. Wondering if you think this is better than the CRDT approach ?
I had the idea to use CRDTs in the beginning (https://github.com/MichaelMure/git-bug/blob/5751cd8f6befa7e5dab6e647d9747f5f20f188b3/notes#L39-L54), but thinking more about it I found out that I could leverage git's datastructure and guarantees to solve the conflict problem. For example, git will, by default, refuse to update a reference in a non-fast-forward way. That means that you can't remove a commit and the associated operations. You can only add some new one. That means that you have to rebase properly your operations before pushing your changes. You don't need to have a git-bug aware remote. As a general rule, I think staying as close as possible to the normal git use-case make git-bug a less special use-case, and reduce the risk of incompatibility.
That said, it might be a good idea to have a hook available that an admin could install to make refuse a push with invalid data.
But anyway i was thinking about how lots of users have to fork and then manage setting up the brnahc and then doing a PR. It can be tricky for new golang users. SO i want to suggest that this be incorporated later. I saw a repo in golang just the other day that did this.
Hmm, I'm not sure what you are talking about, can you clarify ? If you mean that user have to clone the depo and use git-bug to submit a new bug, well, no necessarily. The web UI is designed to, in the future,
be used as a public interface as well. It would need to have some kind of authentication to identify users though.
The code base looks really clean and easy to follow and i want to congratulate you on this excellent work.
Thanks ! Also, golang being quite picky about circular-reference force you to have a cleaner design ...
In terms of a github server, do you envisage users using gitea or other ?
You can use whatever git server you want, whatever network transport you want. Even a repo in a mounted filesystem can be used as a remote if you want to. That's how the tests are run.
Deleted user (ghost) commented
hehe. Yeah i found your repo when searching for graphql.
Thanks for all the info and answering my questions
i should explain what i meant about the old Fork, Branch dance.. See links
git-bug is entirely decoupled from the normal files and branches used for the code of your project. That means that a bug is not stored in a specific branch or anything. As a fork is simply another git remote, you can push/pull your bugs there as well. No special tooling needed in git-bug for that IMHO.
I found another golang project t that does all this using Mage. So all good.
Your project is super cool.
You should have a look at activity streams spec and golang implementation.
It will make it easier to imitate that aspect of the GitHub experience
around issues and comments. Then use your project as the data store
git-bug is entirely decoupled from the normal files and branches used for
the code of your project. That means that a bug is not stored in a specific
branch or anything. As a fork is simply another git remote, you can
push/pull your bugs there as well. No special tooling needed in git-bug for
that IMHO.
On Wed, 8 Aug 2018, 13:25 Ged Wed, gedw99@gmail.com wrote:
Good points.
I found another golang project t that does all this using Mage. So all
good.
Your project is super cool.
You should have a look at activity streams spec and golang implementation.
It will make it easier to imitate that aspect of the GitHub experience
around issues and comments. Then use your project as the data store
git-bug is entirely decoupled from the normal files and branches used for
the code of your project. That means that a bug is not stored in a specific
branch or anything. As a fork is simply another git remote, you can
push/pull your bugs there as well. No special tooling needed in git-bug for
that IMHO.
Michael Muré (MichaelMure) commented (edited)