On Tue, Feb 6, 2018 at 3:20 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Tue, Feb 6, 2018 at 3:04 PM, Elijah Newren <newren@xxxxxxxxx> wrote: > >> >> Does anyone have an idea what may have happened here or how to avoid it? > > According to Peff this got fixed > https://public-inbox.org/git/20171020031630.44zvzh3d2vlhglv4@xxxxxxxxxxxxxxxxxxxxx/ > and but you've had a corrupted repo from back when you were using an older > version of Git. > > Did that repo exist before d0c39a49cc was rolled out? Then we can keep that > hypothesis of "left-over corruption" as Peff put it. I'm somewhat confused by this explanation. That precise commit is the one I bisected to that _caused_ the fetch to fail. Also, there might be one important difference here -- in the link you provide, it suggests that you had a corrupted working directory that made use of a now gc'ed commit. In the case I was able to dig into, we did not. (There was a left-over .git/worktree/<something> that had a now gc'ed commit, but no working directory that used it.) I suspect you mean that there was another previous bug that induced corruption, that this commit fixed that other bug, while also introducing this new bug that makes folks' clones unusable because the error doesn't provide enough information for users to know how to fix. It took me hours to figure it out, after users ran out of ideas and came and asked me for help. (Maybe if I was familiar with worktree, and knew they had been using it, then I might have guessed that "HEAD" meant "not your actual HEAD but the HEAD of the vestige of some other worktree"). Does anyone have pointers about what might be doable in terms of providing a more useful error message to allow users to recover? And/or ideas of what steps could cause corruption so I can send out a PSA to help users avoid it? If not, I'll try to dig more, but I thought I'd ask others familiar with this area.
