Stop building the invoker twice in the sample
Labels: chore, good first issue
Size: XS · Priority: low
Problem
samples/GitHttpBackend.Server/Program.cs:105-107 logs which git-http-backend was
found — a genuinely useful startup line — but gets the path by constructing a second
invoker:
app.Logger.LogInformation(
"Serving git repositories from {ProjectRoot} (auth mode: {AuthMode}, git-http-backend: {BackendPath})",
projectRoot, useBasic ? "basic" : "none", new GitHttpBackendInvoker(options).BackendPath);
MapGitHttpBackend already built one at
src/GitHttpBackend.AspNetCore/GitHttpBackendEndpointExtensions.cs:26, with the comment
"Constructed once: resolves and validates the backend path up front". The second
construction runs GitBackendLocator.Locate() again, which starts another git --exec-path process and repeats the file-existence checks. It is startup-only and
harmless, but it contradicts the comment two files over and there is a cleaner shape
available.
Proposed change
Add an overload that takes a caller-owned invoker, so the host can construct it once and
keep the resolved path:
public static IEndpointConventionBuilder MapGitHttpBackend(
this IEndpointRouteBuilder endpoints, string prefix, GitHttpBackendInvoker invoker)
The existing (prefix, options) overload stays and delegates to it, so nothing breaks
for current callers. GitHttpBackendInvoker already exposes BackendPath publicly, and
HandleAsync currently takes options only for the Authorize hook — check whether the
invoker should expose the options it was constructed with, or whether the overload should
accept both.
Then the sample becomes:
var invoker = new GitHttpBackendInvoker(options);
// … log invoker.BackendPath …
var endpoint = app.MapGitHttpBackend("/", invoker);
which also means a bad BackendPath fails before the log line rather than after it.
Acceptance criteria
Stop building the invoker twice in the sample
Labels:
chore,good first issueSize: XS · Priority: low
Problem
samples/GitHttpBackend.Server/Program.cs:105-107logs whichgit-http-backendwasfound — a genuinely useful startup line — but gets the path by constructing a second
invoker:
MapGitHttpBackendalready built one atsrc/GitHttpBackend.AspNetCore/GitHttpBackendEndpointExtensions.cs:26, with the comment"Constructed once: resolves and validates the backend path up front". The second
construction runs
GitBackendLocator.Locate()again, which starts anothergit --exec-pathprocess and repeats the file-existence checks. It is startup-only andharmless, but it contradicts the comment two files over and there is a cleaner shape
available.
Proposed change
Add an overload that takes a caller-owned invoker, so the host can construct it once and
keep the resolved path:
The existing
(prefix, options)overload stays and delegates to it, so nothing breaksfor current callers.
GitHttpBackendInvokeralready exposesBackendPathpublicly, andHandleAsynccurrently takesoptionsonly for theAuthorizehook — check whether theinvoker should expose the options it was constructed with, or whether the overload should
accept both.
Then the sample becomes:
which also means a bad
BackendPathfails before the log line rather than after it.Acceptance criteria
GitHttpBackendInvokerexists.(prefix, options)overload is unchanged in behaviour and signature.