Question: can git-bug "branch" and "merge" (similar/same as regular git files/content)? about git-bug HOT 24 CLOSED

In the data model of SIT (a somewhat similar project to this one), making issues branchable was one of the original "must have features". Being designed around a simpler primitive of a file set (instead of depending on Git or any other system), it's all just files, potentially checked into a repo. Once they are checked in, they are branched at will and there are no merge conflicts because all files are considered immutable.

I personally find this to be a very useful feature for back-porting, distinguishing between production/master and particularly pinpointing the state of an issue to any revision ("how did it look exactly here?", "is this fixed on 1.0 branch?", etc.)

from git-bug.

As for other trackers, as I mentioned before, SIT is not only branch-aware but revision-aware as its shares the namespace with the normal files (when used in conjunction with SCM). This has its pros and cons. Main con is that it exposes these files and their changes to the users. Some pros are: being able to pinpoint issue state, being able to affect issue(s) from within patches, easing transition between version control tools, etc.

I believe that issues can't be "global" -- their content and state always have a context. That's why the design choice to make this data live alongside with the primary content was made.

From what I remember, I don't remember any decentralized (and merge-conflict-free) issue tracker do anything similar. Though I might have missed some.

from git-bug.

@berkus bugseverywhere gain this feature by storing bugs data in regular branches, which is something git-bug try to avoid. The question is rather if and how git-bug should be made aware of the normal coding process.

I see two possibilities:

• an "active" solution: git-bug listen (via hooks) to events in git (commit, merge ...) and trigger bug changes from that
• a "passive" solution: git-bug store extra metadata (for example, what branch is concerned by the bug, what commit fix it), and is able to compute on demand the bug status (is the bug fixed in the current branch ?)

A passive solution would be easier imho, but this needs more though. This is not only a technical question, it's also what feature do we really want here.

from git-bug.

I believe the main value of the approach taken by issue trackers that store their data alongside the code is that it has the effect of merging in the state changes to bugs along with their fixes.

I think something similar could be achieved by tracking both the bug-introducing commit and each commit that fixes the bug in the bug's metadata. This wouldn't be as automatic as having the bug metadata stored alongside the code. But it would enable automated traceability and discovery of branches that contain the bug (without a fix).

from git-bug.

First of all - git-bug looks awesome @MichaelMure . I was thinking to myself last night "it would be cool if something like this existed", and I found it today!

In my mind though, I'd like the bug operations to be tied to the source commits. That way, I could be working on fix-branch, mark the bug as "closed", but the bug remains "open" on the master branch until I merge fix-branch in (after CI passes and whatnot).

Most of the issue / bug tracking software I use today is modeled the way that git-bug works though - I just think it's suboptimal in a git-first world.

I think there might be some clever ways to still keep the refs/bugs data outside of the source commits, but achieve the same goals. The refs/bugs tree could mimic the exact structure of the source refs, with merge commits that always tie the refs together. It would probably get tricky with rebasing though...

from git-bug.

Hmm, I'm not sure what you have in mind. Could you explain in more details your usecase ?

from git-bug.

Here's my first attempt at the thought, which is designed more to catalyze others' thought process, and possibly less to exactly specify:

Document, requirements, bugs, feature requests: they can be context-sensitive to branches just like source code is. So, as an illustration, can a bug follow and "adapt" to a branch same as the source-code does?

A possibly different, additional feature:
Most all other systems require a bug to manually track all the related branches (to the bug). It might be nice for a "built-in" (like git-bug) system to do this implicitly, or some flavor of "automatically."

from git-bug.

This discussion raises two really important questions for me.

There are two wishes and their own use cases backing them.

1 "branch insensitive". - You want bugs ( which is a type of document) to be global ( branch independent) to a repo and so reference issues across different paths.
@MichaelMure is talking about this.

2 "branch sensitive". - You want documents to live in branches.
@yrashk is talking this this

--

I can see both being really useful. Branch Sensitive expands the use cases to allow the Git repo to be used as a Document Store and Synchronisation system, which is pretty cool. THis whole area is being explored using CRDT, OT, etc etc and is really had to get right. It's a hugely valuable thing to me i admit because it really allows expansion of the use cases.

I dont want to push either, because git-bug has its focus and Branch sensitive is expanding the scope.
Also Branch sensitive ONLY works with no potential merge conflicts because its uses OT / Lamport clock techniques. This allows merges from one branch into another and with the lamport clocks allows ordering and so removes potential conflicts.
@yrashk A very neat trick and i gotta say good stuff as lots of people being trying hard to get that working well.

If your curius see the Go implemenation: https://github.com/hashicorp/serf/blob/master/serf/lamport.go

from git-bug.

@gedw99 in my case, I solved this without lamport clocks but rather a content-addressable DAG. Each record in SIT can reference 0..n parents and this forms a DAG. With this, and each record (which is just a directory with files) being immutable, I am avoiding merge conflicts.

from git-bug.

For the record, Lamport clock are used in git-bug only to order bugs between each other. There is no clock involved inside a single bug. The ordering of the edit operations is fixed by the chain of commit and the position of each operation in the array of OperationPack.

from git-bug.

Just to confirm — current version of git-bug does NOT track bugs differently in different branches; and bug state is thus global to the repository?

from git-bug.

@berkus That's correct. The data model and the storage is entirely decoupled from the normal code.

But it's still possible to make git-bug understand what a branch is and make it track where and how a bug is resolved.

It would be interesting to see which bug trackers have this feature and how they handle this problem.

from git-bug.

http://www.bugseverywhere.org/ is also tracking bugs in branches and "merges" ticket resolution together with branch merges.

from git-bug.

FYI: git-dit allows cross-referencing between issues and from one issue to an arbitrary revision using the parent references of a commit.

For accumulating metadata and other mechanics confined to a single issue, we only use the first parent of a commit. All other parents are considered references to data external to the issue. This allows, for example, to refer to a revision in which an issue was resolved when closing it. We don't have any real tooling for using those references yet, though.

from git-bug.

Extra metadata seems a good idea and simple enough.

Plugins or extensions could then work with them to do more complex things if required.

from git-bug.

Per ghost's comment:

Can some current or future solution (git-bug or otherwise) support both modes?

eg: possibly start each issue/bug creation with a "global" or a "branch" context. Or something else, not sure.

(Apologies if this was already covered above or somewhere else.)

from git-bug.

It's not the focus at the moment, but yes, entirely possible.

from git-bug.

@MichaelMure (the presumed leader of this project's effort) - great, thanks for the timely reply.

My proposal:

Unless we want to leave this issue open to find other solutions that are "git branch friendly," let's close this issue for now - especially if this project likes to reduce the number of open issues. My motivation for launching this issue has been addressed.

Separately:

If my team is able at some point in the future, we'll offer some solution path to deliver this "git-branch friendly option mode" feature with minimal or zero changes to git-bug. For now: pls close this issue, particularly if the git-hub project likes to reduce their number of open issues.

@MichaelMure - does that work?

from git-bug.

I'll keep the issue open, it help curious people to get some context about the development, and i can point them to if they are curious about this subject.

from git-bug.

@MichaelMure - that sounds great.

Further, if there's any future thing I can do for you and/or your project now or in the future, please do not hesitate to message me. It seems like you and your team are doing great work here.

[And please do not hesitate to be persistent if you or others are seeking assistance. This communications channel is one among many for me, and it's hard to keep current with every channel - so if you need to repeat a request for help, please do not take it personally. Additionally: my name here is an avatar, and not my real name, of course.]

Warm regards,
~J

from git-bug.

Thanks for the kind words. The team at the moment is composed of:

• myself, working on git-bug on the side of my regular job
• @a-hilaly, who joined through the google summer of code program, also working on the side of his normal student commitment
• a few people contributing occasionally

If you want to help, I'd say do as with any free software: make it yours, use it, report bugs of feature request and if you can contribute in the form of code or documentation (very useful !). There is also an OpenCollective that could be useful someday. I'm still curious who you actually are though ;)

from git-bug.

Checking in after some time away: has anyone thought more about this?

It seems as if there's not much (if any) additional interest (beyond mind) in this feature, at least judging by this issue's activity.

from git-bug.

@yrashk - where is this "SIT" project you (I think?) mention. I've been unable to find it.

Separately:

A collection/list of distributed-bug-tracking (often git oriented), I hope it's okay for me to record here, for my reference (apologies if I'm hijacking this issue inappropriately):

https://dist-bugs.branchable.com/software/ (git-bug is of course referenced here, introduced by @MichaelMure back in 2018).

The more-interesting (to me) additional pages from above website:
https://dist-bugs.branchable.com
https://dist-bugs.branchable.com/use-cases

from git-bug.

@yrashk - where is this "SIT" project you (I think?) mention. I've been unable to find it.

https://github.com/sit-fyi/sit (also listed on https://dist-bugs.branchable.com/software/ btw.)

from git-bug.