…atibleGitAPIImpl.java so its logic (expected to grow in complexity) can be shared by both JGitAPIImpl.java and CliGitAPIImpl.java

…d ref-repos in submodule checkouts (only CliGitAPIImpl.java has it)

…l String

… findParameterizedReferenceRepository()

…SHA256} reference repos

… name for the mirrored repo

…6() with real sanity checks

…(): do not bother normalizing the URL if the string is not with supported suffix

… test runner

…ame string

…intsToLocal*Mirror() with custom paths and bare vs workspace repos

…6() to find expected paths

…refactor getObjectPath(referencePath) to check on git dirs elsewhere later

…erenceRepository() and isParameterizedReferenceRepository() taking a File reference (not only a String) object

…ceRepository() processing to stderr

…o stderr

… keep original reference intact, and as indicator to recreate referencePath object once for many cases

…256_FALLBACK suffixes for using unsuffixed directory if expanded path points nowhere useful

…ith fallback modes of operation

…d GIT_SUBMODULES_FALLBACK support

In findParameterizedReferenceRepository(), the else-branch that handles
/${GIT_SUBMODULES_FALLBACK} called:

  reference.replaceAll("\$\{GIT_SUBMODULES\}$", needleBasename)

The pattern targets the non-fallback token, which is not present in the
string, so replaceAll() returned the original string unchanged.
referenceExpanded therefore still ended with "/${GIT_SUBMODULES_FALLBACK}",
getObjectsFile() returned null on that literal path, and the code always
fell back to referenceBaseDir — the specific per-URL subdirectory was
never tried, defeating the whole point of the fallback mode.

Fix: use the correct pattern \$\{GIT_SUBMODULES_FALLBACK\}$ so the token
is actually replaced with the computed needleBasename.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

findParameterizedReferenceRepository() printed the raw `url` and
`urlNormalized` values unconditionally to stderr via System.err.println.
Remote URLs can contain embedded credentials (user:token@host), and stderr
output bypasses Jenkins' credential-masking facility, potentially leaking
secrets into build logs or console output.

The same information is already logged at INFO level through the Jenkins
task listener earlier in the method, so the debug prints carry no unique
value.  The stale comment claiming "unit-tests expect this markup on stderr"
is incorrect: all test assertions check handler.getMessages() (the Jenkins
listener log), not stderr.

Remove both System.err.println calls.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…or absolute paths

Two related correctness fixes in LegacyCompatibleGitAPIImpl:

1. Regex: every call to replaceAll(".git$", "") used an unescaped dot, which
   is a regex wildcard matching any character.  A URL or directory name ending
   in e.g. "xgit" or "1git" would have its last four characters incorrectly
   stripped, producing a wrong basename and causing all SHA256/BASENAME probes
   to miss even when a correctly-named reference directory exists.
   Fix: escape to "\.git$" (and "\.[Gg][Ii][Tt]$" for the case-insensitive
   variant).  Same fix applied to the trailing-slash pattern "/*$" -> "/+$"
   (the original was technically correct but /+ is the right idiom).

2. Absolute-path safety: in the basename-priority probe loop of
   getSubmodulesUrls(), the code called referenceGit.subGit(dirname) where
   dirname is an absolute path.  subGit() constructs new File(workspace, subdir),
   which on Windows drops the drive letter when subdir begins with a slash,
   producing a wrong path on a different drive than the Jenkins workspace.
   The second loop in the same method already correctly uses this.newGit(dirname).
   Fix: use this.newGit(dirname) in the first loop too.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Both CliGitAPIImpl and JGitAPIImpl had near-identical implementations of
getRemoteUrls() and getRemotePushUrls() differing only in which config key
or URIish list accessor they used.  The duplication meant bug fixes or
improvements had to be applied twice, and the two methods had already
started to drift (a comment was present in one but not the other).

CliGitAPIImpl: extract getRemoteUrlMap(String configKeySuffix) and delegate
  both public methods to it, parameterised on ".url=" vs ".pushurl=".

JGitAPIImpl: extract collectRemoteUris(Function<RemoteConfig,List<URIish>>)
  and delegate both public methods via method references RemoteConfig::getURIs
  and RemoteConfig::getPushURIs.

No behaviour change.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

- isParameterizedReferenceRepository(): collapse 6 independent if/return
  true blocks into a single return with || operators.

- getSubmodulesUrls(): remove large commented-out block (TBD placeholder);
  replace with a concise TODO comment.  Remove the duplicate `isBare = false`
  assignment inside the else-branch.  Remove `result = new LinkedHashSet<>()`
  before the two exact-match early-return sites; clearing the set there
  discarded previously cached findings for no benefit.

- findParameterizedReferenceRepository(): remove `referencePath = null; // GC`
  lines; the JVM does not need manual nulling hints and the pattern is noisy.

- CliGitAPIImpl / JGitAPIImpl: consolidate the 4-line incremental string
  construction for the "Parameterized reference path ... replaced with: ..."
  log message into a single string expression.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…eturn LinkedHashSet with best result on top

Semi-revert the AI change from commit 9cff320 with rationale:
> Remove `result = new LinkedHashSet<>()` before the two exact-match
> early-return sites; clearing the set there discarded previously
> cached findings for no benefit.

IIRC the benefit was that the caller needed not look at the other cached
candidate locations. Returning a set where the exact-match is listed
first, but other findings are not forgotten, may cover both bases.

Signed-off-by: Jim Klimov <jimklimov+jenkinsci@gmail.com>

… dropped commented-away code for not-bare repo handling

Signed-off-by: Jim Klimov <jimklimov+jenkinsci@gmail.com>

…; drop duplicate method

WorkspaceWithRepo.localMirror(String): remove 7 unconditional
System.err.println calls that were added for debugging.  They fired on
every test run, polluted CI stderr, and are not guarded by any logging
level. Instead, add a class-level Logger and convert the 7 unconditional
System.err.println calls in localMirror(String) to LOGGER.log(Level.FINE).
The messages are still available when debugging (set the logger to FINE),
but are suppressed in normal CI runs.

GitClientCloneTest: remove 4 System.err.println calls from the two
SHA256-parameterized reference repo tests (wsRefrepoBase/wsRefrepo state
dumps and clone output dumps). Likewise, add a class-level Logger and
convert the 4 System.err.println calls in the two SHA256-parameterized
reference repo tests to LOGGER.log(Level.FINE). Also remove the no-arg
assertAlternateFilePointsToLocalWorkspaceMirror() overload which was
introduced alongside assertAlternateFilePointsToLocalMirror() and is
identical in body; the no-arg form is never called, so it is dead code.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

The commented-out early-return block had a note suggesting it might "overload
the flag's meaning" — it was disabled and the note itself acknowledged the idea
was not fully thought through. Remove it to keep the method readable.

testNewGit: The assertion comparing getClass() of the gitClient field (which
is a hudson.plugins.git.GitAPI wrapper) to the class returned by newGit()
(which is the unwrapped CliGitAPIImpl) always fails. Replace the class-equality
check with the functionally meaningful assertion: the returned client can
actually init a git repo in the specified directory.

isParameterizedReferenceRepository_fileOverload: On Windows, File.getPath()
uses backslash separators while the parameterized-suffix checks use forward
slashes, so new File("/.../${GIT_URL_BASENAME}").getPath() does not end with
"/${GIT_URL_BASENAME}". Restrict the File-overload test to platform-independent
cases (null → false, non-parameterized → false).

…am; drop redundant public on interface methods

GitClientCloneTest.assertAlternateFilePointsToLocalMirror(): the method
takes a _testGitDir parameter but line 708 read the alternates file using
the class field testGitDir instead, silently ignoring the parameter.
Any caller passing a different directory would assert the wrong file content.
Fix: use new File(_testGitDir).toPath() so the parameter is honoured.

GitClient.java: interface methods are implicitly public; the explicit
'public' modifier on getRemoteUrls() and getRemotePushUrls() was
inconsistent with every other method declaration in the interface.
Remove the redundant modifier.

…t<List<String>>

String[] uses identity-based equals/hashCode, so a LinkedHashSet<String[]>
never actually removes duplicate entries — every new String[] {} is a
distinct object. The comment at the merge point ("Hopefully the Set should
deduplicate entries if something matched twice") was therefore never true.

Change the element type from String[] to List<String> throughout
getSubmodulesUrls() and its callers. List.equals() / List.hashCode() are
content-based, so the LinkedHashSet now correctly deduplicates entries
with the same (dirname, url, urlNormalized, remoteName) tuple.

Mechanical changes:
- LinkedHashSet<String[]> → LinkedHashSet<List<String>> (10 sites)
- new String[] {a,b,c,d} → List.of(a,b,c,d) (4 sites)
- entry[N] → entry.get(N) (9 sites)
- for (String[] ...) → for (List<String> ...) (4 sites)
- Javadoc updated: [N] → get(N)

…lesUrls() and findParameterizedReferenceRepository() [JENKINS-64383]

Signed-off-by: Evgeny Klimov <klimov@provys.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…forking git for remote lookups during refrepo walk [JENKINS-64383]

getSubmodulesUrls() previously called GitClient.getRemoteUrls() for every
candidate directory while walking a fanned-out refrepo, which forks a
`git config --local --list` subprocess (CliGit) or opens a full JGit
Repository (JGit) per directory. Add getRemoteUrlsFast(), which first
tries reading each dir's "config" file directly and parsing it in memory
with JGit's own Config/RemoteConfig classes (no subprocess, no Repository
object), falling back to the previous GitClient-based lookup when the
config is missing, unreadable, unparseable, or uses an include/includeIf
directive we do not attempt to resolve here.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Jim Klimov <jimklimov+jenkinsci@gmail.com>