Thanks. What threw me is that I expected it to be "very fast" and "very cheap" . If I commit a multi-gig file on the server, I see the dry-run fetch takes several seconds (clearly indicating some work proportional to the server repo size). I don't want to transfer that file on a dry-run, I hoped the server and client were both dry-running, andb the server could simply say "here's metadata for what I _would have_ returned if this was real". Not possible? Tim On Tue, Dec 27, 2022 at 4:52 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Tim Hockin <thockin@xxxxxxxxxx> writes: > > > I'm trying to test if a remote repo has a given SHA. `ls-remote` does > > not work for this unless it is a tag or a HEAD (which is not > > guaranteed for this case). > > > > `git fetch --dry-run $remote $rev` SEEMS to fit the bill, except it > > changes local state. For example: > > Well, without changing the "local state", you cannot see if that > report repository has or does not have the commit. > > > FETCH_HEAD was not updated (good) > > None of your refs are updated, either. > > There are things that are not reachable from your refs (or other > anchoring points like the index and the reflog). As far as Git is > concerned, they don't exist [*], and that is why Git will happily > remove them with "git gc", for example. They are crufts and it is > easier to think of them as not a part of "local data". > > So I suspect that ... > > > but the rev in question is now > > present locally (bad), > > ... this complaint is a bit misguided. After all, the procdure you > gave above is exactly how you would ask the "I'm trying to test if a > remote repo has a given SHA" question about commit f80f1b23b4ca. If > the operation did not transfer data, you would not be able to get > the answer to that question. > > > Am I using --dry-run wrong (or misunderstanding its purpose)? > > Maybe (mis)understanding on Git's data model (see above [*]) is the > root cause of this confusion.
