Skip to content

gl repo create prints a View: URL on gitlawb.com that 404s for any repo not on node.gitlawb.com #370

Description

@Vasanthdev2004

What happens

gl repo create prints a View: URL that 404s for any repo not hosted on node.gitlawb.com.

Creating a repo against a self-hosted node:

$ GITLAWB_NODE=https://origin.gitlawb.com gl repo create my-repo
✓ Created repository: my-repo
  Clone: git clone gitlawb://did:key:z6Mk…/my-repo
  HTTP:  https://origin.gitlawb.com/z6Mk…/my-repo.git
  View:  https://gitlawb.com/z6Mk…/my-repo          ← 404

Clone: and HTTP: are both correct and both work. View: is built against gitlawb.com regardless of which node the repo was just created on:

https://gitlawb.com/<did>/<repo>
  → 307 → https://explorer.gitlawb.com/repos/<did>/<repo>
  → 404

The explorer is backed by the main network, so it can only resolve repos that node knows about. Confirmed by asking each node directly for the same repo:

node /api/v1/repos/<did>/<repo>
origin.gitlawb.com 200
node.gitlawb.com 404
node2.gitlawb.com 404
node3.gitlawb.com 404

Why it matters

This is the first thing a self-hosting operator sees after their first successful command, and it is the one line of the three that is wrong. The failure is also silent in the unhelpful direction: the URL is well-formed and the 307 makes it look like it resolved somewhere real, so the natural conclusion is "my repo did not get created" rather than "this link was never going to work".

Anyone posting or sharing that link — which is what a View: line invites — shares a 404.

Two things tangled together

  1. The URL is unconditional. View: should be derived from the node the repo was created on, or omitted when that node has no known web view. Printing a link to a service that cannot see the repo is worse than printing nothing.

  2. origin.gitlawb.com has no peers, so nothing it hosts can propagate anywhere the explorer could find it:

    $ curl https://origin.gitlawb.com/api/v1/peers
    {"count":0,"peers":[]}
    

    That may be intentional for that particular node, but it means (1) is not a display bug alone — there is genuinely no URL that would work for this repo today. Worth deciding separately whether that node should be peered and added to bootstrap-peers.json.

Suggested direction

For (1): only print View: when the target node is one with a known web view — or make the web view host a property the node advertises on GET /, alongside did and version, and print the line only when the node supplies one. That keeps the CLI from hardcoding a topology it cannot verify.

Environment

  • gl @ fad75a6, reports gl 0.7.1
  • node origin.gitlawb.com, v0.7.1, network: alpha

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingcrate:glgl — the contributor CLIkind:bugDefect fix — wrong or unsafe behaviorsev:lowCosmetic, cleanup, or nice-to-havesubsystem:visibilityPath-scoped visibility and content withholding

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions