Feature request: Import from JSON?

[arcanemachine]

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

[smoyer64]

Maybe I'm missing something but I use git-bug on several machines and just use git bug push and git 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]

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]

I'll have to run some tests but this week is pretty busy. I'm thinking the process of using git-bug on the second machine is probably the critical step and I'll document it if I get it working.

[arcanemachine]

Well I got git bug push/pull working... Not sure what I did differently this time. I just created a new user, did a git bug pull, and everything worked as one would expect. Glad to have multiple backup options working!

I'm still using the dev build that I compiled myself FWIW.

[mcepl]

Maybe I'm missing something but I use git-bug on several machines and just use git bug push and git 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?

JSON files are easier to back up, and also it adds robustness for the situations when git-bug is broken, and it is not possible to migrate from higher to lower version. Like right now.

[github-actions[bot]]

This bot triages untriaged issues and PRs according to the following rules:

• After 90 days of inactivity, the lifecycle/stale label is applied
• After 30 days of inactivity since lifecycle/stale was applied, the issue is closed

To remove the stale status, you can:

• Remove the lifecycle/stale label
• Comment on this issue

[mcepl]

This is still completely alive.