RE: [Bug] git fetch --dry-run --filter makes changes to .git/config

From: Kevin Puetz <puetzkevina@johndeere.com>
Date: Sep 19, 2025, 15:31 UTC
Message-ID: <DS0PR05MB10013365E4D3BACFF71ACBAACB511A@DS0PR05MB10013.namprd05.prod.outlook.com>
In-Reply-To: <022401dc28ea$8be87d40$a3b977c0$@nexbridge.com>

> If I might ask, and I realize this is an edge-condition, but what is the intent when
> the clone has been done with a --depth=1 or similar? The single commit may not
> be known locally but may be in the history as far as the remote is concerned. I am
> just curious.

Definitely in scope, and likely a common scenario for conan. If you have a full clone with remote-tracking branches and such, then `git branch --remote --contains ...` is enough to think the remote has this commit. The case where it has to go online is when something like CI did a `git clone --single-branch` or `git clone ----revision=` and there's not necessarily any tracking branches.

If the remote has the commit in question, shallow or not, we'd still want conan.tools.Git.commit_in_remote to return true. And it looks like --negotiate-only should work fine for that. It looks like, in a shallow clone, the main difference is that the client only sends "have ..." lines for the commits back to the shallow boundary, and then the "0000" flush. Which is correct - it *doesn't* have the earlier parents. The server then responds with ACK or NAK as appropriate to the "have ..." it saw.

Now, that increases the odds that there are no commits in common (if the remote in question has a more-distant ancestor, below the shallow cutoff, the negotiation won't figure that out. But that doesn't cause any harm - the negotiation result is NAK (correct, we don't have anything in common), and if the client does proceed with a fetch it gets everything (which it does need, since it didn't have that early history).

So it seems fine, other than --negotiate-only perhaps triggering the same "fatal: expected 'acknowledgments', received 'packfile'" bug we were discussing for actually-unrelated histories.

Or, if we reverse the roles and make the shallow copy the remote, e.g.
 `git fetch shallow --negotiate-only --negotiation-tips=HEAD~1` (pretty weird).
we get a different error "fatal: expected 'acknowledgments', received 'shallow-info'"
But it's still the same bug - the client sends the weird empty fetch
("wait-for-done", no "have", no "want", no "done"), the server falls through into
`case UPLOAD_SEND_PACK` the same way, but now send_shallow_info writes
that before the packile.

Public