RIght now, the bridge integration is isolated from the native workflow. This complicates the CLI experience (see #1193).

We can (probably) make bridge integration transparent, by storing bridge state locally and refactoring git-bug-{push,pull} to iterate over any configured bridge(s), transparent to the user, such that they do not need to explicitly run git-bug-bridge-{push,pull} in order to interact with the remote.

sudoforge added label area/bridge 1 year ago

sudoforge added label kind/feature 1 year ago

sudoforge added label priority/awaiting-more-evidence 1 year ago

sudoforge added label triage/needs-information 1 year ago

Imho this is not really the problem. Bridges have limitations that translate into UX issues (like the confusion in that comment):

• bridges can't push the events that are not owned by a known account (one we have an auth for), so (almost always) we can't push everything. This alone prevent bridges from being "transparent".
• git-bug on-purpose prevent from pulling from one bridge and pushing to another, because that would cause more problems than it would resolve

Imho, the solution is to try to address the confusion directly. Possibly, rename the push/pull bridge operations to import/export to make then feel less "native" (ie, with limitation)?

This issue is not intending to suggest that we need to change the behavior of the bridge integrations, but rather, how git-bug-bridge-push and git-bug-bridge-pull are executed. To be exact, I want to hook those into the lifecycle of git-bug-push and git-bug-pull, so that the git-bug-bridge-{push,pull} commands can be removed.

The goal here is to orient around a single command for pushing and pulling bugs to both the native namespace and the bridge's API.

bridges can't push the events that are not owned by a known account (one we have an auth for), so (almost always) we can't push everything. This alone prevent bridges from being "transparent".

there's no reason we can't try to push, and emit a warning (or not) if we get an error letting the user know we weren't able to export to the bridge.

git-bug on-purpose prevent from pulling from one bridge and pushing to another, because that would cause more problems than it would resolve

it's possible that there are historical internal decisions that prevent this in git-bug's current form; you would definitely know better than me at this point. i do think it is definitely possible, on a technical level, to associate an entity in git-bug with metadata stating that it came from a specific bridge configuration, which would support this polyglot syncing approach.

but that would require more work. we could keep the enforced limitation of 1 bridge connection in place and still execute on making the import/export workflow transparent.

github-actions (github-actions) added label lifecycle/stale 1 year ago

github-actions (github-actions) added label lifecycle/idle 8 months ago

sudoforge removed label lifecycle/idle-auto 8 months ago

sudoforge removed label lifecycle/idle 7 months ago