Support for forking and then PR ? about git-bug

[MichaelMure]

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 (

git-bug/notes

Lines 39 to 54 in 5751cd8

	G-Set (append only log)
	-----
	- create bug
	- change title
	- add/edit/hide/unhide/delete comment
	LWW-e-Set (add + remove, based on timestamp)
	---------
	- label
	- assignee
	- project
	- milestone

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

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

https://blog.sgmansfield.com/2016/06/working-with-forks-in-go/

https://stackoverflow.com/questions/14323872/using-forked-package-import-in-go

[MichaelMure]

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.

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

…

On Mon, 6 Aug 2018, 14:01 Michael Muré, ***@***.***> wrote: 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. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwo2lmFnkmdZC-sxWl1mbXeh9IaZlks5uODAlgaJpZM4Vvh2b> .

Check it out http://go-fed.org/

…

On Wed, 8 Aug 2018, 13:25 Ged Wed, ***@***.***> 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 On Mon, 6 Aug 2018, 14:01 Michael Muré, ***@***.***> wrote: > 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. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#9 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ATuCwo2lmFnkmdZC-sxWl1mbXeh9IaZlks5uODAlgaJpZM4Vvh2b> > . >

[MichaelMure]

http://go-fed.org/

This goes nowhere.

it worked 2 days ago. I guess something is down. here is the github repo: https://github.com/go-fed

…

On Wed, 8 Aug 2018 at 18:08 Michael Muré ***@***.***> wrote: http://go-fed.org/ This goes nowhere. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATuCwpM4PLGB1X9eJwz43exG2H2ulKIxks5uOw0ZgaJpZM4Vvh2b> .