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

Public
On 2025-09-17 at 14:44:00, Kevin Puetz wrote:

quoted

    the .git/config file was modified, adding

    [remote "origin"]
        promisor = true
        partialclonefilter = tree:0

I will note that if this command actually downloads any data, this is
required.  That's because your repository is incomplete: you want to
download exactly one commit and without marking the promisor remote, you
will lack the ability to acquire trees or blobs and your repository will
then be corrupt.

I agree - had I actually stored the fetch, this would be correct behavior.
It was surprising/wrong *only* because --dry-run threw away the resulting objects

quoted

I did not expect any changes to the local clone (due to the use of --dry-run)

I agree --dry-run should not change your repository.  However, I would
also say that it should not contact the server, either

Hmm. I'm not sure I agree there. Usually --dry-run is intended as a way
to find out of the command is going to give any errors, and that's the sense
in which conan is using it. I could see it not actually downloading the pack from
the server, but I'd of expect it to at least negotiate which refs are needed
(and thus fail if the server doesn't have them). Which it currently does.

But I wasn't expecting it to make any lasting changes to the local clone,
So that seemed like a bug I ought to report (though it's admittedly quite a corner-case)

quoted

Context is https://github.com/conan-io/conan/issues/18949
trying to avoid a full-re-download in the process of checking
whether the HEAD commit hash exists in a remote.
The command was expected to either be a no-op success, or fail

I don't think that the command you've provided is a good or efficient
way of doing what you want, but I'm also not sure that there's a good or
efficient way to do what you want using command line Git (you might need
to write a small portion of the protocol, for instance).

I certainly agree that the `fetch --refetch` conan 2.0 is currently doing is a very inefficient
way to check if a remote has a certain commit or not - which is why I was
experimenting with blobless/treeless to minimize the useless transfer.

Today I also found `git fetch $REMOTE --negotiate-only --negotiation-tip=$COMMIT`.
That supposedly (and seemingly in practice) replies with the list of ancestors,
we have in common, i.e. it will print the same $COMMIT if the server has it,
or some list of ancestor(s) we share if it does not. That seems like a much more
sensible command to check whether the remote has a commit,
so I'd also appreciate any feedback if I'm there's something wrong with using it this way.

I did find one odd quirk. When the remote and the requested commit are unrelated
e.g. I'm taking to the wrong remote, or have done `git checkout --orphan`), I get

$ git fetch https://github.com/git/git --negotiate-only --negotiation-tip=$COMMIT
fatal: expected 'acknowledgments', received 'packfile'

This still works for conan's purpose (exiting with an error means it didn't print a matching commit hash),
but I expected something more like the "fatal: remote error: upload-pack: not our ref: ..."
error that you get from git fetch {remote} --refetch $COMMIT. Of course, unexpectly sending a packfile
could be a problem with github's server implementation, rather than the git client.

--
brian m. carlson (they/them)
Toronto, Ontario, CA