Git.run / GitSync: tls_verify config passthrough is broken (-c placement, --config vs -c, inverted sslVerify) #533

Summary

GitSync(..., tls_verify=...) is meant to toggle http.sslVerify when cloning, but the path is broken by three distinct, interrelated bugs that surface once tls_verify actually reaches Git.clone(config=...).

Discovered alongside the git_shallow/tls_verify constructor-attribute fix in #531 — passing those kwargs previously raised AttributeError, which masked everything below.

B. Top-level git options are placed after the subcommand

Git.run builds the argv as ["git", <subcommand>, ...] and then appends top-level options (-C, --config, --git-dir, --work-tree, --namespace, ...). Git requires these before the subcommand. So config={"http.sslVerify": False} yields:

git clone --progress -- <url> <dir> --config http.sslVerify=false
# fatal: Too many arguments.

instead of:

git -c http.sslVerify=false clone --progress -- <url> <dir>

This affects every subcommand that forwards config= (or any other top-level option) through run(), not just clone.

C. --config is not a top-level git option

The same block (L260-L261) emits --config name=value, but git's top-level config option is -c name=value. git --config ... reports unknown option: --config.

D. tls_verify=True inverts the meaning of TLS verification

GitSync.obtain sets config={"http.sslVerify": False} if self.tls_verify else None, so tls_verify=True disables certificate verification and tls_verify=False leaves the default. The flag name implies the opposite.

Reproduction

from libvcs.sync.git import GitSync

repo = GitSync(url="https://example.invalid/repo.git", path="...", tls_verify=True)
repo.obtain()  # clone fails: "fatal: Too many arguments."

With the #531 fix tls_verify=True sets the attribute; the clone then fails on the mis-placed --config. Before that fix it raised AttributeError.

Suggested fixes

• B: emit top-level options between "git" and the subcommand in Git.run (e.g. a global_flags list applied before args).
• C: emit -c name=value instead of --config name=value.
• D: map tls_verify directly to http.sslVerify (true/false) and reconsider the default so tls_verify=True means "verify".

Acceptance

• A Git.run/Git.clone test asserts the generated argv places -c name=value before the subcommand.
• GitSync(tls_verify=...).obtain() applies the intended http.sslVerify value over an HTTPS remote.