Summary of Changes

All tests pass. Here's the summary:

Bug: When git-sync sync is run against a public source repo (e.g. https://gitlab.baylibre.com/...), it would interactively prompt for username/password on a host the user had never authenticated against.

Root cause (internal/auth/auth.go:69): git credential fill falls back to an interactive terminal prompt on /dev/tty when no configured helper has credentials. git-sync is non-interactive, so this prompt shouldn't happen — anonymous access should be attempted instead.

Fix: Set GIT_TERMINAL_PROMPT=0 on the git credential fill invocation. With this, when no helper has credentials, git exits non-zero, our existing code treats that as "no credentials found", and we proceed anonymously. I also extracted newCredentialFillCmd so the env-var contract is unit-testable (TestCredentialFillCmdDisablesTerminalPrompt).

Proposed Options

So you have two options:

Option A — ship the current fix. Bug #63 (interactive prompt) is fixed. Cost: we still call git credential fill proactively, so if you have stored credentials for a host, we'll attach them on requests that didn't need auth. For most users this is harmless, but it does mean we send a token to a public repo we didn't need to.

Option B — match git's actual behaviour. Change Resolve() to skip the helper lookup, then make HTTPConn retry on 401 by consulting the helper at that point. Outline:

• auth.Resolve() returns nil when only the helper would have credentials (don't call it eagerly)
• Add a CredentialProvider callback on HTTPConn that calls git credential fill
• In RequestInfoRefs and PostRPC, on a 401 response, call the provider, retry once with the returned creds
• On retry success, also call git credential approve; on persistent 401, git credential reject

That's roughly a 100-line change touching auth/, gitproto/smarthttp.go, and a few tests. Slightly more if we want to handle 401s mid-stream during the pack post (which we should, since some servers only challenge on git-upload-pack not /info/refs).

User Discussion

My instinct: the bug filer just wants the prompt to stop. Option A solves that today. Option B is the better long-term shape and worth filing as a follow-up, but I'd rather propose it cleanly than wedge it into this PR. Want me to:

1. Ship Option A and open a follow-up issue for Option B, or
2. Do Option B now as part of this fix?

Behavior Changes

Here's the summary of what we built:

Behaviour change: git-sync now matches git's own HTTP auth behaviour — try anonymous first, only consult the credential helper on a 401 response from the server.

Files changed:

• internal/auth/auth.go — Resolve() no longer eagerly calls git credential fill. New GitCredentialHelper type with Lookup/Approve/Reject methods that shell out to git credential with GIT_TERMINAL_PROMPT=0 so it never prompts.
• internal/gitproto/smarthttp.go — New CredentialHelper interface on HTTPConn. RequestInfoRefs retries once on 401, stores resolved auth for subsequent calls (e.g. PostRPC), and signals approve/reject back to the helper.
• internal/syncer/syncer.go — Wires auth.GitCredentialHelper{} onto HTTP conns when no explicit auth was configured.
• Tests: 7 new HTTPConn 401-retry tests + 8 new auth helper tests + updated TestResolve to assert the helper is never consulted up-front. The pre-existing TestRun_IntegrationUsesGitCredentialHelperFallback end-to-end test still passes — it now exercises the new 401-retry path against a real httptest server.

The net effect: For the user in issue #63, syncing from a public GitLab repo now works without prompting — git-sync makes the request anonymously, the server returns 200, no helper is ever consulted. For users with private repos and a configured helper, the helper is consulted only when needed.

Further Considerations

Here’s one thing we could add here: Let's say I talked to a host that needs credentials and I enter the right ones, then it's saved in the helper. If they expire, the next time I run git-sync I get a 403.

Implementation Plan

Where to wire it in git-sync:

• lookupGitCredential returns a func() error (the "reject closure") alongside the username/password, capturing the input it sent to fill
• The session-level code wraps the AuthMethod with that closure
• On 401, the session calls the closure (which runs git credential reject for the same input).

Conclusion

In summary, based on the detailed review and the changes suggested, I will go ahead and create a PR for #63 now, as proposed.

Additional Cleanup Summary

• Dropped duplicate struct; use utility directly in the retry path
• Enhanced approval/rejection methods
• Introduced helper to consolidate tests and reduce redundant logic