Question: can git-bug "branch" and "merge" (similar/same as regular git files/content)? #922
Replies: 24 comments
-
|
Hmm, I'm not sure what you have in mind. Could you explain in more details your usecase ? |
Beta Was this translation helpful? Give feedback.
-
|
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: |
Beta Was this translation helpful? Give feedback.
-
|
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.) |
Beta Was this translation helpful? Give feedback.
-
|
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. 2 "branch sensitive". - You want documents to live in branches. -- 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. If your curius see the Go implemenation: https://github.com/hashicorp/serf/blob/master/serf/lamport.go |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
@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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
http://www.bugseverywhere.org/ is also tracking bugs in branches and "merges" ticket resolution together with branch merges. |
Beta Was this translation helpful? Give feedback.
-
|
@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:
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Extra metadata seems a good idea and simple enough. Plugins or extensions could then work with them to do more complex things if required. |
Beta Was this translation helpful? Give feedback.
-
|
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). |
Beta Was this translation helpful? Give feedback.
-
|
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... |
Beta Was this translation helpful? Give feedback.
-
|
Per ghost's comment: Can some current or future solution ( 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.) |
Beta Was this translation helpful? Give feedback.
-
|
It's not the focus at the moment, but yes, entirely possible. |
Beta Was this translation helpful? Give feedback.
-
|
@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 @MichaelMure - does that work? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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, |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the kind words. The team at the moment is composed of:
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 ;) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
@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/ ( The more-interesting (to me) additional pages from above website: |
Beta Was this translation helpful? Give feedback.
-
https://github.com/sit-fyi/sit (also listed on https://dist-bugs.branchable.com/software/ btw.) |
Beta Was this translation helpful? Give feedback.
-
Question: can git-bug bugs "branch" and "merge" (similar/same as regular git files/content)?
If not, does it make sense to add such a feature in the future?
Beta Was this translation helpful? Give feedback.
All reactions