Repository navigation
Conversation
mcepl
marked this pull request as draft
September 24, 2026 11:33
mcepl
force-pushed
the
gitea_bridge
branch
4 times, most recently
from
September 25, 2026 17:16
ccc88d2 to
c3b1d49
Compare
This was referenced Sep 25, 2026
mcepl
force-pushed
the
gitea_bridge
branch
3 times, most recently
from
September 25, 2026 20:34
54b05df to
ce833ae
Compare
mcepl
force-pushed
the
gitea_bridge
branch
4 times, most recently
from
October 3, 2026 08:28
cd322a5 to
a9adb24
Compare
When git-bug.identity in the local git config points to an identity that doesn't exist in the repository (removed, never pulled, or the config was copied from another repository), several code paths failed with the cryptic "identity doesn't exist" error: - core.FinishConfig, used by every bridge's "bridge new", only treated identity.ErrNoIdentitySet as "no user configured" and aborted on any other error. Bridge configuration could therefore never complete, while the credential had already been stored, so every retry left another orphaned token in the keyring. - LoadRepoEnsureUser / LoadBackendEnsureUser returned the raw ErrNotFound, giving the user no hint about what is missing or how to fix it (identity.GetUserIdentity silently unsets the dangling config at that point too). FinishConfig now checks the configured user identity first. When a dangling identity is detected, it prints a notice and repairs it by adopting an existing identity tagged with the bridge login if one exists, or by creating a new tagged identity and setting it as current. The ensure-user helpers are factored into ensureUser(), which turns the not-found case into an actionable message pointing to "git bug user adopt" / "git bug user new". Regression tests cover FinishConfig with a dangling identity, both when a matching identity exists and when a new one must be created.
auth.List returned credentials in whatever order the keyring backend listed its keys, which is arbitrary. Callers in all bridges (github, gitlab, jira importers and exporters) simply use creds[0], so when several matching credentials exist, e.g. after a token was regenerated or a bridge configuration was retried, the bridge could keep picking an old, revoked token. The newly added valid one was silently ignored and every pull failed with an authentication error from the remote. Sort the result by creation time, most recent first, with the ID as a tie breaker so that the order is fully deterministic. Stored timestamps preserve full RFC3339Nano resolution so credentials added in the same second still sort deterministically newest-first, while remaining backward compatible with legacy integer timestamps. Adding a fresh credential now supersedes older ones for every caller without having to touch each bridge.
Bridges for self-hosted trackers (gitlab, jira) only select credentials carrying a "base-url" metadata matching their configuration, but "bridge auth add-token" had no way to set it. Tokens added through it were therefore never used by those bridges, without any warning. Add a -b/--base-url flag, consistent with "bridge new", which stores the value as base-url metadata on the token. Also report a clear error when --user doesn't match any identity. "-u" means --user here but --url in "bridge new", which makes it easy to pass a URL by mistake; previously that produced only the cryptic "identity doesn't exist". The man page and markdown documentation are regenerated.
…lients In githubExporter.cacheAllClient and gitlabExporter.cacheAllClient, the loop over credentials built each client from creds[0] instead of the iterated cred. If tokens existed for multiple accounts, every identity client was configured with whichever token appeared first in the slice. Because auth.List orders credentials newest-first, adding a token for a secondary account caused exports to run with that account's token, even for the configured default login. Build each identity client and assign the default token from the matching iterated token instead of creds[0].
… matching When bridges for trackers like GitLab and Jira query credentials by base URL, auth.List uses exact string matching on metadata. Differences such as a trailing slash (for example, the default "https://gitlab.com/" versus user input "https://gitlab.com") caused credential lookups to fail silently, making valid tokens unusable by the bridge. Introduce auth.NormalizeBaseURL to canonicalize URLs by lowercasing scheme and host and removing trailing slashes. Apply this normalization when storing base-url metadata in "bridge auth add-token" as well as in GitLab and Jira bridge configuration. In auth.List option matching, compare base-url metadata values after normalization so queries match regardless of trailing slashes in either the stored credential or the query filter.
Contributor
Author
|
This is unmanageably messy, I will reorganise it few reviewable commits. This is a mess. Unconsolidated version is in https://codefloe.com/mcepl/git-bug/src/branch/gitea_bridge_before_consolidation |
Bridges skip bugs imported from another tracker on push, so a bug cannot be kept in more than one tracker. Add ExportOptions with a Foreign flag and Bridge.ExportAllWithOptions to request that. Exporters opt in through the ForeignExporter interface; for any other bridge the request fails instead of being ignored, and it is enabled before Init so the exporter can verify the remote tracker first. The interface documents the contract for implementations: refuse remote trackers that hold issues not created by mirroring, store remote ids under repository-scoped keys from MirrorMetaKey so they never clash with the metadata of the bridge the bug came from, and credit original authors with MirrorAttribution, because the remote shows everything as written by the token owner.
Expose ExportOptions.Foreign on the command line, describe its rules in the command help and the bridge guide, and regenerate the command reference. No bridge on trunk implements mirroring yet, so the option currently fails with an explanatory error.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
mcepl
changed the title
This comment has been minimized.
This comment has been minimized.
|
Want your agent to iterate on Greptile's feedback? Try greploops. |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is meant as continuation of #1565 (rebase on the current
trunkand also further fixes).This adds a Gitea/Forgejo bridge to
git bug bridge. The importer brings in issues with their comments, comment edits, labels, title changes and open/closed status. There is no exporter yet.It supersedes #1077 and builds on #1565. The history is the work of several people, rebased onto current
trunk:I'm opening this as a draft to get CI results on all platforms and early feedback on the approach.
What works
git bug bridge new --target=giteaaccepts a web URL, a clone URL or an SSH remote, and validates the token and repository.change_title) and close/reopen events are replayed in order, attributed to whoever made them.sinceis sent on both the issue listing and the timeline requests, so later runs fetch only issues and events newer than the last import.<empty string>placeholder the GitHub bridge uses.What doesn't work yet
NewExporterreturns nil, sogit bug bridge pushto Gitea reports that export isn't supported.updateIssueis an empty function; close and reopen events now do what it was meant for.Changes on top of #1565
Build
go.workandgo.work.sumfrom the whole history. They pointed at../go-sdk, a local checkout of the SDK, so the build failed for anyone without it, CI included.gitea.dev/sdk v1.2.0. The code needs the SDK fix that changedTimelineComment.Labelfrom[]*Labelto*Label, which v1.1.0 doesn't have. Also requirepgregory.net/rapid v1.3.0for the property tests.gitea-previewand would fail CI's generated-files check.URL parsing
splitURLpanicked on URLs with fewer than two path segments (https://host/owner). It also forcedhttps, which brokehttp://localhost:3000, and dropped the path of instances installed under a subpath. It now:httpandhttpsas given;git://,ssh://(including a port) andgit@host:owner/reporemotes tohttpson the same host;https://example.com/gitea/);/owner/repo/issues/12.Importer
panic("todo"). They are now imported as status changes.renameevent, but Gitea and Forgejo sendchange_titlewith the new title innew_title. The test fixtures used the same wrong name and are corrected.Documentation
doc/feature-matrix.md. It still described the first draft, which imported only titles and bodies. Comments, comment edits, labels, status, title edits, identities, incremental import with resume and the test suite are now marked as supported. The exporter tables stay ❌.TestImportTitleUnsafeAfterCleanupexpected a title of"\x1b"to fail the import, while two other tests expected an empty-after-cleanup title to get a placeholder. I kept the placeholder and changed that test.Testing
bridge/giteahas 91 test functions: unit tests against the fake API server, iterator tests and property-based round-trip tests. I added tests for two comments on one issue and for a label event whose label was deleted.gofmt,go vet ./...and the generated-files check.-raceeither), and Windows and macOS, which is part of why this is a draft.GITEA_TOKEN_PRIVATE/GITEA_TOKEN_PUBLICto run.Skipped tests:
gitea.dev/[email protected]lacks the needed fields. The branch now uses v1.2.0, so they can probably be enabled.Follow-ups
The changes since the previous review appear safe to merge, with no outstanding previous threads or accepted new findings.Summary
The PR adds a Gitea/Forgejo bridge and updates shared credential, configuration, and push behavior. Since the previous review, the only change replaces the configuration-writing method in two dangling-identity tests. No new actionable issue was established.
Reviews (16) · Last reviewed commit: "bridge/core: update config tests for git..." · Reviewed by Greptile