Repository navigation
Feature request: Import from JSON? #1065
Description
Hello, I know you're busy and this amazing project is already loaded with things to do. I am just wondering at the feasability of something I would like to do: import a JSON file into a freshly-cloned repo and populate a git-bug issue tracker with that data (which would be exported by git bug ls --format json). Sort of like a bridge, but with JSON instead of a specific git provider.
The background is that I've been having trouble with the bridges, both GitLab (I've tried the dev branch, still having issues), and GitHub (this one I should probably troubleshoot more).
Ultimately, what it comes down to is that I really like the git-bug interface, but my issues in dealing with the bridges led me to the realization that git-bug allows you to export the data as JSON. Because I use the issue tracker as a personal to-do list + notepad (and there are no other lightweight TUI programs (that I could find) that match the git-bug experience), if I was able to take that exported data and import it into a copy of the repo on another machine, then I would be able to use the awesome git-bug interface, with full portability, without any dependence on bridges which could break compatibility at any moment.
I hope this idea makes sense, and I hope it could be implemented without too much effort. :)
Thanks
Activity
smoyer64 commentedon May 7, 2023
Maybe I'm missing something but I use
git-bugon several machines and just usegit bug pushandgit bug pull. The main problem with this technique is that you need to create the identity on only one machine and copy it to the other machines. Ultimately, you're also going to want one identity even across repositories too (like you have at GitHub.) Perhaps a DID?Except for sharing between machines, I can envision other reasons for what amounts to a JSON bridge!
arcanemachine commentedon May 8, 2023
Thanks for the reply. I've just been having issues getting any form of portability working (tried GitLab bridge (even with new dev branch), also tried
git bug push/pull), which seem to be related to #1003. I got it working through a GitHub bridge, but I had to set up a repo just for the issues since the original repo is on GitLab.I do think it would be nice to have a bridge using a protocol that won't break due to uncontrollable changes from external sources (e.g. API changes on third-party platforms), but I understand that this project doesn't have as many contributers as it deserves.
smoyer64 commentedon May 8, 2023
I'll have to run some tests but this week is pretty busy. I'm thinking the process of using
git-bugon the second machine is probably the critical step and I'll document it if I get it working.arcanemachine commentedon May 12, 2023
Well I got
git bug push/pullworking... Not sure what I did differently this time. I just created a new user, did agit bug pull, and everything worked as one would expect. Glad to have multiple backup options working!I'm still using the
devbuild that I compiled myself FWIW.mcepl commentedon Mar 21, 2024
JSON files are easier to back up, and also it adds robustness for the situations when
git-bugis broken, and it is not possible to migrate from higher to lower version. Like right now.github-actions commentedon Jul 23, 2024
This bot triages untriaged issues and PRs according to the following rules:
lifecycle/stalelabel is appliedlifecycle/stalewas applied, the issue is closedTo remove the stale status, you can:
lifecycle/stalelabelmcepl commentedon Jul 23, 2024
This is still completely alive.
github-actions commentedon Oct 22, 2024
This bot triages issues in order to help the maintainers identify what
needs attention, according to the following lifecycle rules:
lifecycle/staleis appliedlifecycle/stalewas applied,lifecycle/rottenis appliedThis bot will not automatically close stale issues.
To remove the stale status, you can:
To avoid automatic lifecycle management of this issue, add
lifecycle/frozen.mcepl commentedon Oct 22, 2024
I hate this GitHub bot, and it seems hugely disrespectful to your users to use it.
arcanemachine commentedon Oct 22, 2024
Do you really think insulting the developer is going to encourage them to spend more time on this project? Nobody owes you anything.
mcepl commentedon Oct 22, 2024
And do you think that openly ignoring and disrespecting collaborators on your project will encourage them to help you? Of course, there are probably so endless flocks of collaborators eager to contribute, that the owner of the project doesn’t want anybody else to help. I guess.
There is absolutely no reason for this bot to ever exist. Its only purpose is to hide existing bugs and pretend that the project is in much better shape than it actually is. There is zero cost of having open bugs, we have plenty of integers for new ones, maintainer just wants to show that he/she doesn’t care about their users, and it is more important for them to look like there are no problems than to actually help their users or even to encourage them to help each other.
https://youtu.be/1lYgB_NHFYk
MichaelMure commentedon Oct 22, 2024
There is no endless flock of collaborator. Unfortunately, there is also a shortage of maintainer.
I'm not a fan of that bot either, but as this is a collaborative project, not everything is done your way. And that's ok
7 remaining items
sudoforge commentedon Apr 21, 2025
i thought of a use case i wasn't thinking of earlier: bulk issue creation.
other than importing issues from a third party source (bridge), we don't currently have a way to create issues en masse (without requiring the user to
for f in $FILES; do git bug new --file "$f"; done, but we could make it more ergonomic for sure). i'm not sure i think JSON is the right data format for doing this, but i can totally see the need for a bulk import, and since we export JSON, importing it makes sense.mcepl commentedon Apr 21, 2025
Just to the issue of the stale bot (and I don’t think we need to elaborate on this further): the only good solution of overloading issue trackers in my opinion is fierce and immediate triage on incoming issue reports. Anything else leads to discarding valuable user experience, or to the death of issue trackers, as described in my other comment.
sudoforge commentedon Apr 22, 2025
@mcepl, the bot (rather, the pipeline that does this) is staying.
git-bugis an open source, volunteer-driven project. "volunteer", in this context, means that people are donating their time (sometimes very limited due to other responsibilities), for free, in order to drive a project forward.things will slip through the cracks. the bot helps prevent this.
you are making statements like this:
while not recognizing the fact that without the ability to dedicate one's full attention on a project, this is not possible, especially so in one with a large community and limited maintainers.
i have stated multiple times, as does the bot itself, that it does not close issues. the video you've linked to clearly focuses on automatic closure of issues being the problem, not automatic labeling and commenting (which notifies the maintainers).
to summarize your involvement in this thread:
this is not welcome.