4 ms·

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests e

by rswail 4y ago

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.

efrecon 4y ago
Maybe this? https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue. I've always wanted to give it a spin.
bandie91 4y ago
i worried about the issues/tickets are centralized, too. so i put them in the repo itself as files and asked contibutors to submit tickets by PR into dedicated subfolder. i'd be worth to standardize it.
morelisp 4y ago
For magit users, there's https://github.com/magit/forge https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.
chriswarbo 4y ago
I use https://mrzv.org/software/artemis https://mrzv.org/software/artemis Issues are kept in the repo, inside a .issues folder, so they can be cloned, merged, etc. Each issue is just a maildir, with metadata stored as headers on the top-level message, and comments stored as reply messages. I really like this approach, since there's no need for an always-on server; it's decentralised; I can use any mail client to browse and update the issues (there's also a simple CLI for listing and printing issues/comments); etc. For example, I write artemis issues using the standard message-mode in Emacs, and I render issues to a Web site using MHonArc (a program originally designed to render mailing lists).
WorldMaker 4y ago
On the PR side, I'm pretty strict about PRs requiring merge commits (no fast-forwards/squashes/rebases), because that's a useful in source control history of the PR no matter if you switch hosts. If everything is PRed and all PRs make merge commits `git log --first-parent` in your main branch is your PR history. If PRs are also your unit of CI `git bisect --first-parent` is a bisect on your (PR) integration log. The only thing missing from your "central database" at that point is comments inside the PRs that aren't accounted for in your final merge message in the merge commit.

by rswail 4y ago

efrecon 4y ago

Maybe this? https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue. I've always wanted to give it a spin.

bandie91 4y ago

i worried about the issues/tickets are centralized, too. so i put them in the repo itself as files and asked contibutors to submit tickets by PR into dedicated subfolder. i'd be worth to standardize it.

morelisp 4y ago

For magit users, there's https://github.com/magit/forge https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.

chriswarbo 4y ago

I use https://mrzv.org/software/artemis https://mrzv.org/software/artemis Issues are kept in the repo, inside a .issues folder, so they can be cloned, merged, etc. Each issue is just a maildir, with metadata stored as headers on the top-level message, and comments stored as reply messages. I really like this approach, since there's no need for an always-on server; it's decentralised; I can use any mail client to browse and update the issues (there's also a simple CLI for listing and printing issues/comments); etc. For example, I write artemis issues using the standard message-mode in Emacs, and I render issues to a Web site using MHonArc (a program originally designed to render mailing lists).

WorldMaker 4y ago

On the PR side, I'm pretty strict about PRs requiring merge commits (no fast-forwards/squashes/rebases), because that's a useful in source control history of the PR no matter if you switch hosts. If everything is PRed and all PRs make merge commits `git log --first-parent` in your main branch is your PR history. If PRs are also your unit of CI `git bisect --first-parent` is a bisect on your (PR) integration log. The only thing missing from your "central database" at that point is comments inside the PRs that aren't accounted for in your final merge message in the merge commit.