can you look at the changes in this branch, I want to run the smoke test against a local entire using the linux repo. I did it run once before and it seems no matter what I do it just finishs quickly

I’m checking the branch diff and the smoke-test wiring first so I can see why it’s still targeting the regular CLI repo instead of your local entire Linux repo.

I found the Entire-local smoke test entrypoint. Next I’m reading the branch diff and the test code to confirm which env vars actually switch the source repo and where the fallback to entireio/cli happens.

The fallback is explicit: TestRun_EntireLocalPublicRepoSmoke uses https://github.com/entireio/cli.git unless GITSYNC_E2E_ENTIRE_SOURCE_URL is set. I’m checking the Linux smoke tests too, because they may be what’s finishing quickly and never touching your local Entire target.

The behavior lines up with two separate paths in this branch: test:linux-smoke never touches Entire, and test:entire-local-smoke defaults to the small entireio/cli repo unless you override GITSYNC_E2E_ENTIRE_SOURCE_URL. I’m going to make that less ambiguous in the repo so you can run the Linux-to-Entire case directly.

I’m editing the smoke-test docs and task definitions now. The change is to add an explicit Linux-to-Entire task and make the Entire-local test log the effective source/branch/target so it’s obvious which repo it actually used.

The code change is in place. I’m running a narrow test pass now to confirm the package still compiles after the smoke-test logging and task additions.

The branch is doing two different things, and that’s the source of the confusion.

test:linux-smoke in internal/syncer/live_bootstrap_test.go does not use Entire at all. It bootstraps https://github.com/torvalds/linux.git into a disposable local bare Git repo over git-http-backend. If you want a running local Entire target, the relevant path is test:entire-local-smoke in internal/syncer/entire_local_smoke_test.go, and that test defaults to https://github.com/entireio/cli.git on main unless you override GITSYNC_E2E_ENTIRE_SOURCE_URL and GITSYNC_E2E_ENTIRE_BRANCH.

I updated the branch to make that explicit:

• added mise run test:entire-local-smoke:linux in mise.toml
• documented the distinction in README.md
• added a test log of the effective source/branch/target in internal/syncer/entire_local_smoke_test.go

Use this for the case you described:

Or directly:

Verification: go test ./internal/syncer -run TestLoadEntireHostsWrappedFormat -count=1 passed.

The failure is on the Entire target side now, not on repo selection. I’m checking whether this branch already supports batched relay for the Entire-local smoke path, because the error is a 2 GiB request-body cap during a single bootstrap push.

The branch already has a batched bootstrap path; the Entire-local smoke test just wasn’t using it. I’m wiring batch/max-pack env overrides into that test and switching the Linux-to-Entire task to a batched default so it stays under Entire’s 2 GiB body cap.

The fix is in. I’m running a targeted test compile again so we don’t leave the smoke test broken by the new env parsing.

The failure is expected with the current single-pack path: your local Entire is rejecting a single bootstrap request larger than 2147483648 bytes. The Linux repo is too large for that mode.

I updated the branch so the Entire-local smoke can take batching settings from env, and changed mise run test:entire-local-smoke:linux to use batched bootstrap by default with protocol v2 and a 512 MiB batch cap. I also added test:entire-local-smoke:linux:single if you want the old behavior for comparison.

Run this again on the updated branch:

You should now see the test log include the effective config, including protocol=v2 and batch_max_pack_bytes=536870912. The relevant changes are in internal/syncer/entire_local_smoke_test.go, mise.toml, and README.md.

Verification: go test ./internal/syncer -run TestLoadEntireHostsWrappedFormat -count=1 passed.

I’m searching the codebase for that exact progress text so I can tell whether it’s emitted by git-sync, git, or the Entire server side.

That output is not coming from git-sync itself.

In this repo, git-sync only emits its own progress lines with a [git-sync] prefix via internal/syncer/syncer.go and internal/syncer/syncer.go. The lines you pasted:

are being forwarded from the target server during receive-pack. In the push path, git-sync sets req.Progress = os.Stderr in internal/syncer/syncer.go, so sideband progress from the remote gets printed directly to your terminal.

So those messages are coming from your local Entire Git backend while it is processing the push, not from the source repo selection logic and not from local git CLI output generated by this repo. The “replicas” wording strongly suggests server-side object replication/storage progress inside Entire’s backing Git service.

Practical read:

• [git-sync] ... lines are from this branch.
• unprefixed “Sending to replicas…” / “Storing objects…” lines are remote target-side progress from Entire.

If you want, I can trace where the push is switching from single-pack to batched in this run and what log lines to expect next.

The repo name on the Entire Git backend is git-sync-smoke-2.

From the test log, the full target path was https://localhost:8080/git/test/git-sync-smoke-2, so it’s repo git-sync-smoke-2 under user test.

Use git as the HTTP username, not test.

This smoke test pushes to:

• repo: git-sync-smoke-2
• URL: https://localhost:8080/git/test/git-sync-smoke-2
• auth used by the test: basic auth with username git and the Entire token from your local Entire login

That comes from internal/syncer/entire_local_smoke_test.go, where the target endpoint is set with Username: "git" and Token: token.

So for git clone, use:

and when prompted:

• username: git
• password: your Entire token

If your local Entire uses a self-signed cert, you may also need:

If you want, I can show you how to pull the same token source the smoke test is using from your local Entire config/keyring.

I’m checking whether entire-git-helper is present here or referenced in config so I can answer from the local setup instead of guessing.

I found the relevant code in your local entire checkout. It uses the system keyring under the hood; the helper can supply credentials to Git, but it isn’t a token-dump command.

Yes, if by “get it from the helper” you mean using the Git credential-helper protocol.

In your local entire checkout, the helper command is entire auth git-credential, and its get operation reads from the keyring and prints:

• username=...
• password=...

That behavior is in auth.go and is covered by auth_test.go.

For your local host, you can do:

If the active user for that host is already set in hosts.json, you can usually omit the username:

That should print the token as the password= line. The helper is just a front door to the same keyring entry the smoke test is using.

Not quite.

If the total source data for that branch fits under GITSYNC_E2E_ENTIRE_BATCH_MAX_PACK_BYTES, batched mode should usually collapse to a single effective batch, so it will be close to non-batched bootstrap. But it still has extra overhead from the batching path itself:

• checkpoint planning on the source side
• extra protocol-v2 graph inspection
• batch/resume bookkeeping
• temp-ref handling logic

So the practical answer is:

• if the repo fits in one batch, performance should be similar
• it will usually be a bit slower than plain non-batched bootstrap
• it should not be dramatically slower unless the planning/probing overhead dominates for a very small repo

The real tradeoff is:

• non-batched is the fastest simple path when one push fits comfortably
• batched is the safer path when you might hit target body-size limits or want resumability

In this branch, batched mode is most useful for large repos like Linux against Entire’s 2 GiB limit. For smaller repos, plain bootstrap is still the cleaner baseline.

Yes, you could unify it, but not with a cheap “repo size” lookup that reliably answers the real question.

The key point is that the limit you hit is not “repository size on disk”. It’s “size of the HTTP push body for this specific ref update against this specific target”. Those differ a lot because push size depends on:

• which branch/ref you’re sending
• what objects the target already has
• packfile compression/delta behavior
• whether tags are included
• protocol/capabilities
• whether you’re doing initial bootstrap or incremental sync

So a cheap preflight like “ask the source repo how big it is” is not enough.

What is inexpensive

• Checking whether the target is empty.
• Looking at the branch tip / advertised refs.
• For already-batched mode, this branch already does sample-based pack-size checks while planning checkpoints.

What is not inexpensive

• Knowing the exact pack size up front.
• You usually need to either generate the pack, or at least walk enough of the object graph to estimate it.
• For large repos, that estimation work is a meaningful chunk of the total job.

Practical design that makes sense

1. Try normal bootstrap first.
2. If the target rejects the push with a known size-limit error, automatically retry with batched bootstrap.
3. Optionally allow a config knob like --auto-batch-max-pack-bytes or default batching threshold for Entire targets.

That is better than trying to predict perfectly from repo size, because it optimizes for the common case:

• small/medium repos stay on the fast simple path
• large repos fall back automatically when needed

If you want a more proactive version, the branch could also do:

• if target is Entire and empty, probe/estimate first
• if estimated pack exceeds threshold, switch to batched
• otherwise use single-pack bootstrap

But that estimate is not free. It would likely reuse the same machinery as batched planning, so once you do that, you’ve already paid much of the batching overhead.

So my recommendation is:

• unify behavior at the sync entrypoint
• prefer single-pack first
• auto-fallback to batched on known target body-limit failures
• optionally remember that this target needs batching for future runs

That gives the simplest UX without making every sync pay an up-front estimation tax.

If you want, I can sketch exactly where in this branch to add the automatic fallback.

I’m tracing the bootstrap and sync call paths now to add an automatic fallback from single-pack relay to batched relay on known target body-limit failures, without changing the fast path for smaller repos.

I’ve confirmed both bootstrap and auto-bootstrap from sync funnel through the same bootstrapWithInputs helper, which is the right insertion point for the fallback. Next I’m checking the surrounding Run logic and existing tests so I can add this without regressing the normal relay path.

I have the integration points. Now I’m looking at the in-process HTTP test server so I can simulate the exact “body exceeded size limit” failure and cover the new retry path with a regression test.

I need the exact shape of a synthetic receive-pack failure so the regression test hits the same error parser as a real target. I’m checking the go-git pack protocol types now rather than guessing at the wire format.

I’ve got the fallback design. I’m checking the existing Run empty-target bootstrap tests so I can add one regression at the sync entrypoint instead of duplicating coverage on both Run and Bootstrap.

I have enough context. I’m editing the relay path now: a known target body-limit failure during bootstrap will trigger one automatic retry using batched bootstrap at a conservative default batch size, and I’m adding an integration test around the sync path.

The fallback logic is patched in. I’m adding a test target that rejects oversized single-pack pushes with the same unpack error: ... body exceeded size limit ... shape you saw, then I’ll exercise Run to verify it retries into batched mode automatically.

I spotted one important issue while wiring the test: a fixed 512 MiB retry size won’t validate well against a smaller synthetic limit, and it’s also less adaptive than it should be. I’m tightening the fallback so it parses the target’s advertised size limit and picks a conservative batch size from that automatically.

The code changes are in. I’m formatting the touched files and then running the new targeted integration test plus the existing narrow smoke-related test to verify the fallback path end to end.

The targeted test run is in flight. I’m waiting on the new integration case because it has to build a large enough pack to trigger the retry path.

The first attempt didn’t cross the synthetic cap, so the fallback never triggered. I’m tightening the test fixture now so the initial pack is guaranteed to exceed the limit while each per-commit batch still fits comfortably underneath it.

The fixture is fine; the issue is the fallback was deriving too small a retry batch from the advertised limit. I’m adjusting that heuristic from limit/4 to limit/2, which still stays conservative for real 2 GiB limits but behaves much better on smaller caps and in tests.

The initial bootstrap pack is still smaller than the synthetic cap. I’m dropping the test limit one more notch so the first push definitely trips the guard while the batched replay can still fit.

The pack is compressing harder than the smaller fixture suggested. I’m scaling the test data up materially now rather than continuing to shave the limit; that should make the first push exceed the cap deterministically while keeping the fallback batches well below it.

The payload is still compressing too well because the current fixture has a short repeating pattern. I’m changing the large-blob generator to use a simple xorshift stream so the test data is effectively incompressible and the request-size limit actually gets exercised.

The new fixture is doing more real work now. I’m waiting on the targeted test again; if this one still misses the limit I’ll add a direct assertion on the first request size and stop tuning blindly.

The fallback is being blocked by the test server, not the new logic: our in-process v2 source stub only advertises fetch=thin-pack, while batched bootstrap correctly requires filter. I’m updating the v2 test server to advertise filter so the retry path can actually run in integration.

The v2 source stub now advertises the capability batching needs. I’m waiting on the same targeted test again; this run should tell us whether the retry path is actually completing rather than just being selected.

The retry is reaching batched planning now, but the in-process v2 source stub was still wrong: it ignored have lines, so every sample looked like a full-pack fetch and no checkpoint could ever fit. I’m fixing that test server behavior next.

The server-side test shim now accounts for haves. I’m waiting on the targeted run again; if this passes I’ll do one broader package pass over the syncer tests that are directly affected by the changed code paths.

The fallback itself is working; the remaining failure is in the test harness. Batched bootstrap finishes, then the in-process smart-HTTP server mishandles the final command-only temp-ref deletion and returns empty packfile. I’m patching that server to support command-only receive-pack requests so the test reflects real target behavior.

The test server now supports command-only cleanup pushes. I’m waiting on the targeted test one more time; if it passes, I’ll follow with a slightly broader package run on the impacted bootstrap and integration tests.

The remaining failure is just test-server noise: the planner intentionally stops reading some sample fetches early, and the stub currently treats that client disconnect as a test failure. I’m relaxing those writes to ignore expected broken-pipe/reset errors.

The noisy client-disconnect path is patched. I’m waiting on the targeted run again; after that I’ll run a focused set of the existing bootstrap/integration tests that exercise the same code we changed.

The new regression is passing. I’m doing one broader targeted pass over the existing bootstrap and integration cases that share this path, to make sure the fallback didn’t disturb normal bootstrap or batched bootstrap behavior.

sync/auto-bootstrap now retries into batched bootstrap automatically when the target rejects the initial single-pack push due to a body-size limit.

In internal/syncer/syncer.go, the bootstrap relay path now:

• detects known target size-limit errors like body exceeded size limit ...
• parses the advertised limit when present
• derives a conservative retry batch size from that limit
• retries once through the existing batched bootstrap path if the source supports v2 filter

I also added a regression in internal/syncer/integration_test.go that exercises Run(...) against a target which rejects oversized receive-pack requests, and I extended the in-process v2 test server there so batched bootstrap can be exercised realistically.

Verified with:

I did not run the full package or the live Entire/Linux smoke after this change.

Use the same Entire-local smoke test, overriding the source URL and branch with env vars.

Example:

Useful knobs:

• GITSYNC_E2E_ENTIRE_SOURCE_URL: source repo to sync
• GITSYNC_E2E_ENTIRE_BRANCH: source branch
• GITSYNC_E2E_ENTIRE_REPO: repo name to create/use on Entire
• GITSYNC_E2E_ENTIRE_PROTOCOL=v2: optional, but useful for batching
• GITSYNC_E2E_ENTIRE_BATCH_MAX_PACK_BYTES=...: optional explicit batch size
• GITSYNC_E2E_ENTIRE_MAX_PACK_BYTES=...: optional hard cap
• GITSYNC_E2E_ENTIRE_SKIP_TLS_VERIFY=true: if your local Entire cert is self-signed

With the new fallback, you usually do not need to decide batch vs non-batch yourself. Just run it with the repo you want; if the initial push is too large and the source supports the required v2 features, it should retry batched automatically.

If you want a reusable one-liner for a specific repo, for example:

If you want, I can add a generic mise task like test:entire-local-smoke:any that takes SOURCE_URL, BRANCH, and REPO from your shell env.

I’m checking the current default branch for kubernetes/kubernetes, because this failure means the source repo exists but main did not match any advertised branch refs.

kubernetes/kubernetes is still on master, not main as of April 10, 2026. GitHub shows master on the repo page: https://github.com/kubernetes/kubernetes

Use:

Your failure was just the branch mismatch. no source refs matched means the repo was reachable, but refs/heads/main did not exist.

No. That run only synced master.

The smoke test passes Branches: []string{branch} in internal/syncer/entire_local_smoke_test.go, and your log shows branch=master, so it targeted only refs/heads/master.

If you want all branches, you currently need a different invocation path, because this smoke test is intentionally single-branch. For all branches into Entire, use the CLI directly instead of the smoke test, for example:

That will default to all source branches unless you pass --branch.

One caveat: the current auto-fallback-to-batched work you just had me add only applies to the bootstrap path for the initial empty-target case. So if “all branches” produces a push that’s too large, it may still need more work depending on how the multi-branch bootstrap path behaves against your Entire limit. If you want, I can add an “all branches” Entire smoke test/task next.

$GITSYNC_E2E_ENTIRE_TOKEN is probably empty in that shell.

If --target-token gets an empty value, the next auth path falls back and you can end up with an interactive prompt for https://localhost.

Check it first:

If it prints nothing, export a real token or fetch it from the Entire credential helper:

That will print:

Then run:

One more detail: for an empty target, sync will try bootstrap automatically. Since this repo is large, I’d force v2 so the new auto-batch fallback can engage if needed:

If you want, I can add support for pulling the Entire token automatically in the CLI path too, so you don’t have to pass --target-token at all for local Entire runs.

entiredb is not the credential-helper binary here. The helper path is on entire, not entiredb.

Use:

If entire is not on your PATH, use the built binary path directly, for example from your local repo:

or after building it:

entiredb auth is just the login/session management CLI. It won’t print the Git token.

For your git-sync command, the simplest flow is:

then:

If you want, I can add local-Entire credential discovery to git-sync itself so this becomes unnecessary.

That explains it: your publish task installs entiredb, git-remote-entire, and related binaries, but not the entire credential-helper CLI.

So right now you likely cannot use entire auth git-credential get from PATH unless you separately built/installed entire.

For the immediate task, the simplest route is still the token the smoke test already used:

• the smoke test resolves the active Entire user from hosts.json
• then reads the token from the system keyring under service entire:<host>

You have two practical options:

1. Reuse the token by passing it explicitly. If you already know it, use --target-token.

2. Add token auto-discovery to git-sync. This is the better fix for your workflow:

• if target host looks like Entire local
• and --target-token is omitted
• look up the active user/token the same way TestRun_EntireLocalPublicRepoSmoke already does
• then proceed without prompting

That would let this just work:

Given where you are, I’d implement that instead of making you scrape credentials manually.

I’m checking the sibling entire checkout directly so I can answer from the current tree rather than from stale assumptions.

You’re right. In the current ../entire tree there is no cmd/entire anymore.

What exists now:

• cmd/entiredb
• cmd/git-remote-entire
• cmd/entire-server
• cmd/entire-core
• cmd/entire-deploy
• cmd/entire-backup

So the old entire auth git-credential get path is stale.

The current auth/client path is entiredb, and the current Git integration is git-remote-entire. The repo’s own docs say the credential-helper approach was replaced by git-remote-entire, and auth now comes from entiredb auth login. Relevant current references:

• cmd/entiredb/cli/auth.go
• cmd/git-remote-entire/main.go
• README.md
• docs/adrs/20260119-custom-git-remote-transport.md

So for your earlier git-sync prompt issue, the right conclusion is not “use entire auth git-credential get”. It’s:

• either pass a valid token explicitly
• or teach git-sync to discover credentials the same way the current entiredb/client code does

If you want, I can inspect the current entiredb auth storage path and wire git-sync to use that instead of the older keyring-based assumption.

I’m tracing the current entiredb auth login storage path in the local entire tree so I can tell you exactly which files and stores it writes to now.

I’ve confirmed hosts.json is one of the writes. I’m checking the tokenstore backend too, because that determines whether the token itself goes to Keychain, Secret Service, or a file fallback on your machine.

entiredb auth login writes to two places:

1. Host/user metadata in hosts.json

• Path: ~/.config/entire/hosts.json by default
• Override: ENTIRE_CONFIG_DIR
• Contents: per-host users plus activeUser
• Code: cmd/entiredb/cli/auth.go, client/credentials.go

1. Tokens in tokenstore

• Default backend: OS keyring
  • macOS: Keychain
  • Linux: Secret Service/keyring
• Service name: entire:<host>
• Username: the Entire username
• Value: encoded access token with expiry
• Refresh token is stored separately under service entire:<host>:refresh
• Code: cmd/entiredb/cli/auth.go, tokenstore/tokenstore.go

If you force file storage instead of keyring:

• Set ENTIRE_TOKEN_STORE=file
• Optional path override: ENTIRE_TOKEN_STORE_PATH
• Default file path then becomes: ~/.config/entiredb/tokens.json

So on your machine, unless you explicitly set ENTIRE_TOKEN_STORE=file, entiredb auth login is writing:

• ~/.config/entire/hosts.json
• tokens into the OS keychain under entire:localhost:8080 and entire:localhost:8080:refresh for user test or whichever user you logged in as

If you want, I can add token discovery in git-sync against this current entiredb storage model.

git-remote-entire is the Git transport helper, not the thing that performs login.

Its job is:

• handle entire://... remote URLs for Git
• resolve the target host/node
• look up the logged-in user and token that entiredb auth login already stored
• use those credentials when speaking Git HTTP to Entire

So the split is:

• entiredb auth login

  • obtains OAuth tokens
  • writes host metadata to hosts.json
  • stores tokens in tokenstore / keychain

• git-remote-entire

  • is invoked by Git for entire:// remotes
  • reads the active user from hosts.json
  • gets the token from tokenstore
  • performs fetch/push over HTTP with those credentials

That’s why the repo docs say the old Git credential-helper approach was replaced by the custom remote transport. You don’t run git-remote-entire directly in normal use; Git discovers it automatically when the remote URL scheme is entire://.

Important implication for your git-sync case:

• git-sync is currently pushing to https://localhost:8080/..., not entire://...
• so git-remote-entire is not involved at all
• git-sync must either:
  • be given a token explicitly, or
  • learn to read the same entiredb auth storage that git-remote-entire uses

So git-remote-entire is solving auth for Git’s custom entire:// transport, but it won’t automatically help git-sync on plain HTTPS URLs.

I’m checking how git-remote-entire reads credentials now so I can tell you whether it’s practical to integrate with it directly or whether git-sync should read the same storage instead.

Yes, we can integrate it, but the right integration is not “use git-remote-entire to print the token”.

git-remote-entire is not designed as a token-export command. It is a Git remote helper that:

• reads the active user from hosts.json
• reads and refreshes the token via client.GetTokenWithRefresh(...)
• then uses that token for HTTP Basic auth internally

You can see that in:

• cmd/git-remote-entire/main.go
• cmd/git-remote-entire/main.go
• cmd/git-remote-entire/main.go

So:

• Can you use git-remote-entire to get the token directly?

  • Not cleanly.
  • It has no “show token” mode.
  • Scraping or abusing it would be brittle.

• Can git-sync integrate with the same auth path?

  • Yes.
  • That is the right approach.

Best option:

• add local Entire auth discovery to git-sync
• reuse the same current storage model as git-remote-entire:
  • client.GetActiveUser(...)
  • client.GetTokenWithRefresh(...)
• only do that when:
  • target token was not explicitly provided
  • and the target host looks like an Entire host / user wants local Entire auth resolution

That would let this work without passing --target-token:

So the short answer is:

• don’t integrate with git-remote-entire as a subprocess
• integrate with the same entire client/tokenstore code it already uses

If you want, I can implement that in this branch.

I’m wiring git-sync to use the current Entire auth storage directly, reusing the same client/token refresh path as git-remote-entire when no target token is provided. First I’m checking module boundaries and where to hook credential resolution in the CLI/syncer path.

The hook point is newTransportConn, which already has auth fallback logic. I’m reading that code and the existing auth tests so I can add Entire-local token discovery there without disturbing normal Git credential lookup.

git-sync doesn’t currently depend on the sibling entire module, so I need to add that explicitly. I’m checking the sibling module path and the current entiredb client types needed for token lookup before I patch go.mod and the auth resolver.

I’m avoiding a hard dependency on the sibling entire module. Instead I’m implementing the current entiredb storage/refresh logic directly in git-sync: read ~/.config/entire/hosts.json, read tokens from the same tokenstore conventions, refresh if needed, and use that token for the HTTPS target when no explicit target token is provided.

I’ve started the auth patch. I’m adding the Entire-local credential discovery helpers now, then I’ll clean up imports and cover it with tests using the file-backed token store so we don’t depend on your real keychain in test.

The resolver hook is in place. I still need to finish the storage backend helpers and clean the imports before it will compile, then I’ll add tests for both hosts.json lookup and file-backed token refresh.

Because that smoke test already does its own auth discovery.

TestRun_EntireLocalPublicRepoSmoke does not rely on git-remote-entire. It:

• reads the active user from ~/.config/entire/hosts.json or ENTIRE_CONFIG_DIR
• looks up the token in the keyring under service entire:<host>
• then sends Git HTTP auth as:
  • username: git
  • password: <that token>

That logic is in internal/syncer/entire_local_smoke_test.go.

Why it still worked with current entiredb auth login:

• current entiredb auth login still writes host metadata to ~/.config/entire/hosts.json
• and by default still stores tokens in the OS keyring via tokenstore
• the key names still line up with what the smoke test was reading: entire:<host>

So the smoke test happened to match the current storage model closely enough.

Why your CLI git-sync sync ... command didn’t work automatically:

• git-sync main path did not have that same Entire-specific lookup
• it only used:
  • explicit --target-token
  • or generic git credential fill
• and neither of those knew about entiredb’s stored token for plain https://localhost:8080/...

So:

• smoke test worked because it had custom Entire auth lookup
• CLI path prompted because it did not

That’s exactly why integrating the current entiredb storage model into the normal git-sync auth path is the right fix.

I’m finishing the normal CLI auth path now. The remaining work is to make resolveAuthMethod read the same entiredb host metadata and token store as the smoke test/current Entire client, then cover it with focused tests.

I’ve finished the storage helpers. Next I’m adding auth tests for the real CLI path: one for direct token pickup from entiredb storage and one for refresh from the stored refresh token when the access token is expired.

The tests are in. I’m cleaning one stray line from the refresh test and then I’ll run gofmt plus a focused auth/integration test pass to make sure the new Entire credential path and the earlier auto-batch fallback both still hold.

There’s one trivial build failure from an unused time import in the new auth test. I’m removing that and rerunning the same focused test set.

The focused test run is in progress again. I’m waiting on it; if the refresh path passes, I’ll do one more sanity run over the empty-target sync/bootstrap cases since both auth and bootstrap logic changed in the same file.

The failure is just host-key mismatch between the test fixture and what go-git’s endpoint parser uses for lookup. I’m switching the tests to key hosts.json and the token store off the parsed endpoint host instead of assuming localhost:8080.

I’ve aligned the tests with the parsed endpoint host key. I’m waiting on the same focused run again; if it passes, I’ll do one last sanity pass over the empty-target sync/bootstrap tests.

The remaining failure is in how git-sync is reconstructing the base URL from go-git’s endpoint. I’m checking the endpoint shape now and then I’ll fix the base-URL builder so token refresh uses the real host:port, not just the host name.

The refresh-path fix is in. I’m waiting on the focused run again; after that I’ll do one final sanity pass over the empty-target sync/bootstrap tests so auth fallback and auto-batching are both covered together.

git-sync now discovers Entire credentials from the current entiredb auth storage when you target an HTTPS Entire repo and do not pass --target-token.

What changed:

• syncer.go now:
  • reads the active user from ~/.config/entire/hosts.json or ENTIRE_CONFIG_DIR
  • reads tokens from the same tokenstore layout entiredb uses
  • supports both OS keyring and ENTIRE_TOKEN_STORE=file
  • refreshes expired access tokens via /oauth/token
• auth_test.go covers direct token pickup and refresh
• the earlier auto-fallback-to-batched bootstrap work is still in place

So this should now work without manually exporting a token, assuming entiredb auth login has already been done for that host:

Verification:

passed.

I did not run the real git-sync sync ... https://localhost:8080/... command against your live Entire instance after the change.

The lookup is still keying the Entire credentials off the wrong host string for https://localhost:8080/.... I’m checking the exact go-git endpoint fields and then patching the auth lookup to use the credential host including the port, which is what entiredb auth login stored.

The bug is confirmed: hosts.json is keyed by localhost:8080, but go-git splits that into Host="localhost" and Port=8080, and my lookup only used Host. I’m patching that now and will rerun the focused auth tests.

The code path is fixed, but the tests were still writing the fixture under the old host key. I’m updating them to use the same host:port credential key and rerunning.

That prompt was caused by a host-key mismatch. entiredb auth login stored your session under localhost:8080, but git-sync was looking up localhost. I fixed that.

Verified with:

which now passes.

Try your command again from this updated tree:

It should now pick up the entiredb session automatically instead of prompting for https://localhost. I haven’t rerun the live command against your local Entire instance myself.

For this command:

the path is:

1. CLI parses sync

• entrypoint: main.go
• this builds a syncer.Config and calls syncer.Run(...)

1. Auth resolution for the target

• in syncer.go, newTransportConn(...) calls resolveAuthMethod(...)
• auth precedence is:
  1. explicit --target-token / bearer token
  2. Entire-local auth discovery from current entiredb storage
  3. generic git credential fill

For your run, it used step 2:

• read active user from ~/.config/entire/hosts.json
• looked up token from entiredb token storage
• refreshed if expired
• then used HTTP Basic auth with:
  • username: git
  • password: <Entire access token>

1. Sync planning logic

• Run(...) probes source refs and target refs
• if the target is empty for the managed refs, it auto-switches to bootstrap relay
• otherwise it does normal fetch/plan/push logic

Because git-sync-smoke-4 was empty, this command used:

• auto-bootstrap relay path, not the normal decode/repack sync path

1. Bootstrap execution

• fetch source pack from GitHub
• try one single-pack push to Entire
• if the target rejects it with a body-size-limit error and the source supports v2 filter, retry as batched bootstrap automatically

So for your successful empty-target large-repo case, the effective behavior was:

• sync
• auto-detect empty target
• switch to bootstrap relay
• authenticate using entiredb session storage
• use protocol v2
• if needed, fall back from single-pack bootstrap to batched bootstrap

If you want, I can add a --verbose/log improvement that prints which auth source was used and whether it stayed on single-pack bootstrap or retried into batching.