Hi list, Hi Michael, I finally found some time to have a closer look at git-bug. As this mail grew rather long, I divided it into sections.
# Resolving/avoiding conflicts: > > This doesn't in itself ensure a lack of conflicts: you additionally > > need to ensure that those edit commands don't conflict between > > themselves, either by making them commute or by making them > > "arbitrarily conflict free" (in this latter case, you run the risk > > of having merges result in something which the user wouldn't > > consider as correct). > > That's a good point, thank you. > > In git-bug, the merge is done when pulling. You rebase your new > changes on top of what the remote has. In a way, it solves conflict by > taking "our" side of the changes if needed. I think it still breaks down when you consider pushed from two sources. For example, consider the following szenario: An issue is reported somewhere and lives in the "main" repository. It is also copied to another repository (e.g. submaintainer, mirror) and the two start to diverge somehow. Both have some comments or data you want to include. Now you need to merge them: you could state that both states are valid and public, but this is only true if all relevant remotes are visible and known to the user. Rather, you'd want to make all data visible through a single repository. With git-dit, we omitted that problem: we modelled issues after mailing list discussions: each new comment, which may contain some metadata, is stored in a separate commit. However, it does not necessarily need to be a linear sequence of "messages". We use "leaf" references referring to the leaves of that "tree of messages". This allows us to transfer the entire thing from one repo to another and back again without running into merge-conflicts. Like git-bug, git-dit needs to aggregate an issue's metadata from messages. Generally, as a maintainer wou want to have some control over that. Hence, in addition to the leaf references, a "head" reference exists for each issue. That "head" reference refers to the "upstream" state selected by the maintainer and is used as the starting point of aggegation. A maintainer can advance the "head" if he/she agrees with the assessment of a user or push another message introducing an arbitrary change to the metadata. # Remotes Btw, we use a git-config option for specifying what remotes to consider when selecting an issue's "head". Rather than a single remote (as you considered in [1]), we use a list of remotes with descending priority. Maybe this would also be an option for you? # Pull-/Merge-requests With git-dit, we considered multiple options on how to support pull- and merge-requests. The approach we currently plan to implement involves yet another set of references: a PR is represented as a reference to the tip of a PR within an issue's namespace. E.g. you can convert an issue into a PR by simply attaching some branch. This could also work for git-bug (e.g. [2]). # "Issue states" I recently finished some initial work on "issue states" [3]: GitHub and similar plattforms give you the possibility to (re-)open or close issues, e.g. an issue is either "open" or "closed". However, traditional bug-trackers feature a more rich set of states, sometimes configurable by the user or admin. We wanted something similar for git-dit, which is one of the reasons why we don't have a (prominent) way of exposing the state to the user, yet. Said traditional bug-trackers usually not only allow for a rich set of states, but also allow specifying transitions between those states. E.g. only a subset of all possible transitions are allowed, possibly even depending on the role of the user tryingto initiate the transition. This doesn't work that well for distributed issue trackers for imo obvious reasons. Instead, issue states follows another idea: instead of having the issue's state be an explicit attribute, is is a property which deferred from the issue's metadata. For example, if an issue has an asignee, it is "assigned"; if some "closed" tag is set, it is closed; if none of the above, it is "new" or "open". The idea is to have maintainers hand out a specification of those states to their contributors. Currently, a YAML format is specified. The concept is purposely left generic. The current downside is that the conditions linking issues to states are not specified. That is, neither what such a condition could be nor how it is represented as a string. However, I currently consider adding at least some basic specification for conditions including their representation. You are welcome to contribute on that front. Btw.: the reference implementation is written in rust, but it could be ported to or reimplemented for go relatively easy. It is based on a purely textual specification living in the same repository. # E-Mail One feature which we wanted to have early on but never decided on how to actually do it was support for email as a transport. For example, we want to allow users to report issues via email. There are a few options, but at least I am not quite happy with any of them, yet. Do you have any plans regarding support for mail-based communication of issues/bugs? Regards, Julian [1] https://github.com/MichaelMure/git-bug/issues/11 [2] https://github.com/MichaelMure/git-bug/issues/9 [3] https://github.com/neithernut/issue-states _______________________________________________ dist-bugs mailing list [email protected] https://kitenet.net/cgi-bin/mailman/listinfo/dist-bugs
