Re: [PATCH/RFC 0/2] bisect per-worktree

Michael Haggerty [off-list ref] 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.