On Thu, Oct 19, 2017 at 10:27:28PM -0700, Stefan Beller wrote: > > If my analysis above is correct, then it's already fixed. You just had > > leftover corruption. > > Well fetching yesterday worked and the commit in question is from > 8/23, the merge 8a044c7f1d56cef657be342e40de0795d688e882 > occurred 9/18, so I suspect there is something else at play. > (I do not remember having a gc between yesterday and today. > Though maybe one in the background?) Even a gc between yesterday and today should have used the new code, which would have been safe. So yeah, maybe it is something else entirely. > I am curious how you can have a worktree owned by multiple > repositories [1] (?). Sorry, I forgot my footnote. I saw this with my "ci" script: https://github.com/peff/git/blob/7905ff395adecdd2bb7ab045a24223dfb103e0e9/ci I check out the contents of my "meta" branch as "Meta", and it contains that script. It basically just waits for ref updates, then walks over all the commits and runs "make test" on them in the background (caching the results, thanks to the git-test[1] script). So I kick off "Meta/ci" in a terminal and forget about it, and magically it builds my commits in the background as I work. It operates in a worktree inside the Meta directory (Meta/tmp-ci), so as not to disturb what I'm doing. So far so good. But I actually have _two_ clones of Git on my system. One on which I do most of my work, and then the other which has the fork we use in production at GitHub. I symlink the Meta directory from the first into the latter, which means they both see the same worktree directory. And somehow running "Meta/ci" in the second corrupted things. I can get some funniness now, but I think it's mostly caused by the script being confused about the worktree existing but not having access to our branches. That's not a corruption, just a confusion. I _think_ I had a bogus HEAD in the worktree at one point, but I may be mis-remembering. I can't seem to trigger it now. -Peff [1] https://github.com/mhagger/git-test
