sync silently ignores remotes without a collab refspec, and reports the count as complete #103

New issue

Open

opened 2026-08-14 08:26:09 +00:00 by a73x · 0 comments

a73x commented

2026-08-14 08:26:09 +00:00

(Migrated from git.a73x.sh)

A remote you added is excluded from sync with no diagnostic, and the summary counts as if it were the whole set.

Reproduced in a repository with two remotes:

$ git remote
a73x
origin

$ git-collab sync
Sync incomplete: 1 of 1 remote(s) failed.
  Failed:    'origin'

"1 of 1" with two remotes configured. a73x is not reported as failed, skipped, or unconfigured — it is absent, and the count reads as complete.

Cause: collab_remotes selects only remotes carrying a +refs/collab/* fetch refspec, which git-collab init adds. A remote added after init has none, so it is filtered out. The doc comment justifies this — "syncing it would just fail on refs that were never meant to travel there" — and that reasoning is sound for a remote that has nothing to do with collab. It is wrong for the common case: you add a second remote precisely because you want your work on it, and the tool quietly disagrees.

The fix is git-collab init (idempotent since 7824bd7b), which is not discoverable from anything the tool says.

Wanted:

Say something. sync knows the repository's full remote list and its own filtered list; when they differ, name the difference: note: remote 'a73x' has no collab refspec and was not synced — run git-collab init to include it.
Make the count honest. 1 of 1 should be 1 of 2, 1 not configured, or the total should be the repository's remotes.
Consider whether sync --remote a73x, naming a remote explicitly, should configure it or at least refuse with the reason rather than behaving as though the request were ordinary. Explicitly naming a remote is a clear statement of intent.

Reported by the user, who reasonably read the behaviour as "git-collab only syncs to origin". From the outside that is exactly what it looks like.

Migrated from git-collab issue 586a1b2c49babf97d7a44e0379f3119cc1145d6d.

Original author: a73x dev@a73x.sh.

A remote you added is excluded from `sync` with no diagnostic, and the summary counts as if it were the whole set. Reproduced in a repository with two remotes: ``` $ git remote a73x origin $ git-collab sync Sync incomplete: 1 of 1 remote(s) failed. Failed: 'origin' ``` **"1 of 1"** with two remotes configured. `a73x` is not reported as failed, skipped, or unconfigured — it is absent, and the count reads as complete. Cause: `collab_remotes` selects only remotes carrying a `+refs/collab/*` fetch refspec, which `git-collab init` adds. A remote added *after* `init` has none, so it is filtered out. The doc comment justifies this — "syncing it would just fail on refs that were never meant to travel there" — and that reasoning is sound for a remote that has nothing to do with collab. It is wrong for the common case: you add a second remote precisely because you want your work on it, and the tool quietly disagrees. The fix is `git-collab init` (idempotent since 7824bd7b), which is not discoverable from anything the tool says. Wanted: - **Say something.** `sync` knows the repository's full remote list and its own filtered list; when they differ, name the difference: `note: remote 'a73x' has no collab refspec and was not synced — run `git-collab init` to include it.` - **Make the count honest.** `1 of 1` should be `1 of 2, 1 not configured`, or the total should be the repository's remotes. - Consider whether `sync --remote a73x`, naming a remote explicitly, should configure it or at least refuse with the reason rather than behaving as though the request were ordinary. Explicitly naming a remote is a clear statement of intent. Reported by the user, who reasonably read the behaviour as "git-collab only syncs to origin". From the outside that is exactly what it looks like. --- Migrated from git-collab issue `586a1b2c49babf97d7a44e0379f3119cc1145d6d`. Original author: a73x <dev@a73x.sh>.