mirror of
https://github.com/stablyai/orca.git
synced 2026-09-22 16:02:32 +00:00
ce3ec4d5ce
* fix(repo-icon): keep a renamed fork's own owner avatar Fork repos always took the upstream owner's avatar, so a renamed fork showed its parent project's logo. Same-name forks (personal copies) still prefer the upstream owner; renamed forks now keep their origin owner across auto-detect, the startup backfill, and the settings avatar refresh. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(repo-icon): re-read repo state before backfill avatar write The startup backfill computed icon updates from a pre-loop snapshot, so an icon chosen in settings while the upstream/origin probes were pending could be clobbered. Re-read the repo after the probes and only migrate an icon that is still the auto-detected GitHub avatar. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(repo-icon): own the fork avatar rule in one shared selector The renamed-fork rule was written out twice — once in the main-process auto-detect and once in the renderer refresh — so the two copies could drift. Move it next to `githubAvatarIcon` as `githubAvatarSlug`, which collapses the renderer resolver to a single unbranched path. Also stop swallowing a rejected origin probe: it cannot tell a renamed fork from a same-name one, so degrading to the upstream owner would flip a renamed fork's stored avatar back to the parent's. Letting it propagate keeps the stored icon, matching how the non-fork path already behaved. Adds coverage for the startup backfill, the third decision point the fix claims, which had none. * test(repo-icon): cover pending backfill icon change --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Brennan Benson <79079362+brennanb2025@users.noreply.github.com>