On Mon, Nov 14, 2011 at 11:45:46AM +0100, Michael Haggerty wrote: > The whole time, victim's .git/HEAD contains "ref: refs/heads/master", > .git/refs/remotes/origin/HEAD contains "ref: > refs/remotes/origin/master", and its packed-refs file contains > > # pack-refs with: peeled > 4c9ebba3c0618bd6238a810013da4a8cd4f2213b refs/remotes/origin/master > > In "remote.git", refs/heads/HEAD contains not a symbolic reference but > the explicit SHA1 "4c9ebba...". This is of course not affected by > running "git fetch" in the "victim" tree. Deleting this file makes the > problem go away. > > > Given that this problem seems to be in the remote protocol rather than > in the refs API, I think I'll stop working on this. I hope that my > observations are helpful to somebody. I didn't recreate the test situation and look closely, but my impression is that this isn't a code bug at all, but rather a design problem in the way we store remote namespaces. That is, we make "refs/remotes/foo/HEAD" a symbolic ref with special meaning, but then fetch into it from the remote's refs/heads namespace, writing remote's HEAD branch into whatever our HEAD symref points to. So one solution is to block fetching of remote branches called HEAD (which I would be OK with). But another is to use a more sensible layout for representing the remote refs, like: refs/remotes/origin/HEAD (a symbolic ref) refs/remotes/origin/heads/master refs/remotes/origin/tags/v1.0 etc. Then the namespaces are properly separated, and the magic remote "HEAD" symref is not in the way. Obviously there's a lot more to it than just tweaking the default fetch refspecs. The ref lookup rules need to be changed to take this into account. There was some discussion about this over the summer (under the subject of possible "1.8.0" changes), but I don't think any work has been done. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html