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

From: Kevin Puetz <puetzkevina@johndeere.com>
Date: Sep 17, 2025, 23:23 UTC
Message-ID: <DS0PR05MB100132C058A3D9D5AA735D905B517A@DS0PR05MB10013.namprd05.prod.outlook.com>
In-Reply-To: <aMsmbU_Cg0L6kOlm@fruit.crustytoothpaste.net>

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

Show 5 quoted lines

> >     the .git/config file was modified, adding
> >
> >     [remote "origin"]
> >         promisor = true
> >         partialclonefilter = tree:0

Show 5 quoted lines

> 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

> > 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)

Show 9 quoted lines

> > 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