Nested collab refs are invisible to the obvious git for-each-ref pattern #89

Closed
opened 2026-08-13 10:11:27 +00:00 by a73x · 0 comments
a73x commented 2026-08-13 10:11:27 +00:00 (Migrated from git.a73x.sh)

The patch layout nests refs — refs/collab/patches/<id>/events and <id>/rev/<oid> — and the natural command to inspect them silently returns nothing:

$ git for-each-ref 'refs/collab/*'
(nothing)

$ git for-each-ref refs/collab | wc -l
81

for-each-ref globs do not cross /, so refs/collab/* matches nothing below the first level, and refs/collab/patches/<id>* does not match <id>/events. There is no error — the empty result looks like an empty answer.

The asymmetry is what makes it a footgun rather than ordinary git trivia: git2's references_glob, which git-collab uses internally, does cross /, and the revision-refs design depends on that (it is why sync's refs/collab/patches/* refspec carries the whole subtree). So the same-looking pattern behaves differently on either side of the library boundary. Someone reading refs/collab/* in the README and reaching for for-each-ref gets silence.

Hit twice in one session while working on this repo: once auditing local ref shapes, and once in a ref-deletion command that reported success while deleting nothing — the loop matched zero refs and the summary count was computed with a different pattern that did match, so it printed remaining: 2 after claiming to delete.

Wanted, in rough order of value:

  • A note in the README's Storage section that these are nested refs and for-each-ref refs/collab (no glob) or refs/collab/** is the way to enumerate them. The layout is documented; the way to look at it is not.
  • Consider whether git-collab should expose the enumeration itself — git-collab refs or similar — so operators are not writing raw git patterns against an internal layout at all. It already knows how to walk them correctly.

Not a code bug: nothing in the repo's own docs or messages suggests the failing pattern. This is about what a user will reach for unaided.


Migrated from git-collab issue 604b5de4f9c51a054a4bf57b4b1db9c169b3fbef.

Original author: a73x dev@a73x.sh.

Close reason: merged in patch e55d15a2

The patch layout nests refs — `refs/collab/patches/<id>/events` and `<id>/rev/<oid>` — and the natural command to inspect them silently returns nothing: ``` $ git for-each-ref 'refs/collab/*' (nothing) $ git for-each-ref refs/collab | wc -l 81 ``` `for-each-ref` globs do not cross `/`, so `refs/collab/*` matches nothing below the first level, and `refs/collab/patches/<id>*` does not match `<id>/events`. There is no error — the empty result looks like an empty answer. **The asymmetry is what makes it a footgun rather than ordinary git trivia:** git2's `references_glob`, which git-collab uses internally, **does** cross `/`, and the revision-refs design depends on that (it is why `sync`'s `refs/collab/patches/*` refspec carries the whole subtree). So the same-looking pattern behaves differently on either side of the library boundary. Someone reading `refs/collab/*` in the README and reaching for `for-each-ref` gets silence. Hit twice in one session while working on this repo: once auditing local ref shapes, and once in a ref-deletion command that reported success while deleting nothing — the loop matched zero refs and the summary count was computed with a different pattern that did match, so it printed `remaining: 2` after claiming to delete. Wanted, in rough order of value: - A note in the README's Storage section that these are nested refs and `for-each-ref refs/collab` (no glob) or `refs/collab/**` is the way to enumerate them. The layout is documented; the way to look at it is not. - Consider whether `git-collab` should expose the enumeration itself — `git-collab refs` or similar — so operators are not writing raw git patterns against an internal layout at all. It already knows how to walk them correctly. Not a code bug: nothing in the repo's own docs or messages suggests the failing pattern. This is about what a user will reach for unaided. --- Migrated from git-collab issue `604b5de4f9c51a054a4bf57b4b1db9c169b3fbef`. Original author: a73x <dev@a73x.sh>. Close reason: merged in patch e55d15a2
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
a73x/git-collab#89
No description provided.