> On 20 Jun 2016, at 01:51, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: >> >>> According to [1], something in that test seems to have been trying to run >>> >>> git update-ref -d git-p4-tmp/6 >>> >>> Similarly in the other failed test. >> >> Ah, OK, that would try mucking with .git/git-p4-tmp/6 but that is >> not a place to have a ref. It will not participate in reachability >> analysis and will end up losing the referents. >> >> Perhaps placing it under refs/git-p4-tmp would fix it (both in >> git-p4 and in tests)? > > Oh, another thing. If these refs are meant to be transient, they > are likely to be per worktree, if "git worktree" managed multiple > worktrees that share the same set of branches and tags are in use. > > I recall we carved out one hierarchy under refs/ as "not shared > across worktrees" (was that refs/worktree/ hierarchy? I didn't > check but please do so when the patch actually is written), and > that hierarchy is the appropriate thing to use for this, I think. Thanks for the hint. It looks like as if the "per worktree" decision is made in "ref.c:466" "is_per_worktree_ref": https://github.com/git/git/blob/3dc84b0c19932ec9947ca4936b6bfd6421ccb1b4/refs.c#L466-L470 In ce414b3 "refs/bisect" was added to a list of prefixes that are per worktree. I could easily add "refs/git-p4-tmp" to this list but I don't think that would be a good solution. I would prefer to go with your suggestion and add "refs/worktree" to the prefix list and then use "refs/worktree/git-p4-tmp". Later on we could move "refs/bisect" to "refs/worktree/bisect" and simplify the "is_per_worktree_ref" code, too. Thoughts? Thanks, Lars-- 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