Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > Hmm, ok, so you are thinking of a remote database with high latency. I > was thinking more of something like LMDB, with latency comparable to > filesystem storage. Not necessarily. The comment was more from conceptual point: "Why share what needs not to be shared?" > These worktree-specific references might be ephemeral, but they also > imply reachability, which means that they need to be visible at least > during object pruning. True, but for bisect in particular, that is moot. You are in sightseer mode, marking various (older) points in time of an existing history that is already anchored by branches and tags. > Moreover, if the references don't live in the > same database with the rest of the references, then we have to deal with > races due to updating references in different places without atomicity. Does that still hold true in the context of bisection? You do not even want atomicity to get in the way when you found this old commit is bad and are about to mark the next one for testing by checking it out. You still want to mark the "bad" one (as it being bad is already an established fact after testing), even if the subsequent checkout of another commit (i.e. update to "HEAD") fails. But these two comments above do take advantage of the fact that we are discussing "bisect" and nothing else. As a set of points to consider in a more general context, I do agree that there are refs and ref-like things that are per-worktree but still has to be part of reachability, which "HEAD" is the prime example ;-), and some of them may want to be part of a transaction. I however think what David has been calling pseudo-refs falls more in the "ephemeral and unnecessary to participate in reachabliity or transaction" category (e.g. CHERRY_PICK_HEAD). And I think the refs used during bisection falls into the same category. > For each worktree, we could then create a different view of the > references by splicing parts of the full reference namespace together. > ... > "git prune" would see the whole namespace as it really is so that it can > compute reachability correctly. I really like this as a mechanism to include refs/ hierarchy, some part of which is shared and some part of which is private. I do not think bisect or pseudorefs needs that, though. -- 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