Repository navigation
Conversation
MichaelMure
left a comment
There was a problem hiding this comment.
Well, as a maintainer, I see the value of having such a bridge, but it's also a bit scary to merge (and have to maintain) a bridge with zero tests, and incomplete like this.
There is a few tiny fixes to do, but the biggest issue is not having the capability to import comments. It seems like it greatly reduce the usefulness of such importer.
Do you think you could implement that part? It seems like there is already the corresponding iterator, it should be "just" a matter of replicating that data into git-bug.
| return | ||
| } | ||
|
|
||
| // Loop over all comments |
There was a problem hiding this comment.
looks like this is a quite important missing feature, no?
| ) | ||
|
|
||
| // giteaExporter implement the Exporter interface | ||
| type giteaExporter struct { |
There was a problem hiding this comment.
this whole exporter could be removed (as it's not used), instead of returning those weird errors
|
Oh for sure; there's significant work to be done before it's remotely merge-able, hence the "WIP" and "Draft" status. I'm not sure when I'll be in a position to do more than I have already, but wanted to at least share the progress of bringing the previous PRs up to a state where they at least compile and run on the current code-base. Thanks for the direction in your comments, though; that will certainly make it easier to make a start on this. :) |
|
Any thoughts on Forgejo vs Gitea? Looks like they should be basically compatible, and have a good amount of momentum behind them. |
|
Software-wise they're currently identical since Forgejo is a soft fork. |
|
They're very much compatible at the moment; Gitea clients will work perfectly with Forgejo servers. I do know some of the people behind Forgejo are also some of the people behind ForgeFed and they're putting a lot of effort into implementing it. If I remember correctly, the primary Gitea maintainers were pretty ambivalent to federated forges, so I can definitely see them diverging in that area further down the line. |
|
To complete the git issue/PR graph: this address issues #349 (bridge), part of #80 (integration). And has related issue on the gitea side at go-gitea/gitea#6519 |
This a just a preview. Not all features are expected to work.
The features aren't yet filled out, and are represented ❓, but are at least present and aligned for readability.
Co-authored-by: Michael Muré <[email protected]>
|
I've had a little time this weekend to poke at this, and have started adding some unit tests (based on those for the Github/Gitlab bridges) to make this easier to develop. Given I'm still learning the language, I figure having a test harness is a particularly good way to proceed. Not sure how far I'll get with the time I have, but… small steps! |
|
This bot triages pull requests in order to help the maintainers
This bot will not automatically close stale pull requests. To remove the stale status, you can:
To avoid automatic lifecycle management of this pull request, add |
|
̇ |
|
Github stale bot considered harmful (Doesn't apply as long as the bot isn't configured to close everything after it becomes ''''rotten'''') |
|
thank you for all of the hard work that's been put into this so far. i'm going to close this for now to help keep the active board clean, but am in no way rejecting the feature suggestion -- this has just been inactive for a long time. if you wish to address the feedback and submit an update, you can always check out this tree like so: feel free to ping me in a comment here to reopen the PR (to avoid needing to create a new one). |
This PR deprecates #1017 (and #890 and #645 before it). I've rebased off current
master, updated the feature matrix to the best of my ability, and built the code to confirm I can pull bugs from a Gitea repo.I've not done anything else so far. I'm very new to Go, so am starting small, but wanted to at least give this a shot because having a Gitea bridge would be valuable to me.