Hi Peff, I only saw this problem arise on Sunday and wrote it off as a fluke while fetching in parallel, but it persisted today, under more controlled circumstances. I wanted to fast-forward a local branch: $ git fetch origin master:master fatal: bad object .alternate error: https://github.com/git-for-windows/git did not send all necessary objects `git grep`ing around, I saw that you added the code producing that error message, in 39b44ba771a (check_everything_connected: assume alternate ref tips are valid, 2019-07-01) and I verified manually through a combination of debugging and instrumenting that `add_one_alternate_ref()` is indeed responsible for that `.alternate`. Now, I think the two factors that trigger this bug over here are: - I had all the objects locally already, as I had pushed from a topic branch to `master` [*1*]. - My worktree's `.git/objects` is connected to an alternate that is connected to the current Git repository (yes, it is circular, long story...) and has refs pointing to commits its alternate that have been gc'ed away. So I see two problems with this error message: - It is not helpful. It should not say `.alternate`, it should mention the ref itself, and ideally even the path of the alternate. - Shouldn't the code be made smart enough to simply ignore (maybe with a warning) refs that point to gc'ed commits? Ciao, Dscho Footnote *1*: No, I do not usually push directly to `master`. The scenario here is that I had rebased Git for Windows' patches on top of v2.24.0, opened a PR for the PR build, everything checked out all right, and then I wanted to "merge" the PR, _without_ an extra merge commit on top.