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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 08/01/2015 07:12 AM, Junio C Hamano wrote:
> On Fri, Jul 31, 2015 at 8:59 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>>
>> It seems to me that adding a new top-level "worktree-refs" directory is
>> pretty traumatic. Lots of people and tools will have made the assumption
>> that all "normal" references live under "refs/".
>> ...
>> It's all a bit frightening, frankly.
> 
> I actually feel the prospect of pluggable ref backend more frightening,
> frankly ;-). These bisect refs are just like FETCH_HEAD and MERGE_HEAD,
> not about the primary purpose of the "repository" to grow the history of refs
> (branches), but about ephemeral pointers into the history used to help keep
> track of what is being done in the worktree upstairs. There is no need for
> these to be visible across worktrees. If we use the real refs that are grobal
> in the repository (as opposed to per-worktree ones), we would hit the backend
> databas with transactions to update these ephemeral things, which somehow
> makes me feel stupid.

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.

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. 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.

The refs+object store is the most important thing for maintaining the
integrity of a repo and avoiding races. To me it seems easier to do so
if there is a single refs+objects store than if we have some references
over here on the file system, some over there in a LMDB, etc. So my gut
feeling is for the primary reference storage to be in a single reference
namespace that (at least in principle) can be stored in a single ACID
database.

For each worktree, we could then create a different view of the
references by splicing parts of the full reference namespace together.
This could even be based on config settings so that we don't have to
hardcode information like "refs/bisect/* is worktree-specific" deep in
the references module. Suppose we could write

[worktree.refs]
	map = refs/worktrees/*:
	map = refs/bisect/*:refs/worktrees/[worktree]/refs/bisect/*

which would mean (a) hide the references under refs/worktrees", and (b)
make it look as if the references under
refs/worktrees/[worktree]/refs/bisect actually appear under refs/bisect
(where "[worktree]" is replaced with the current worktree's name). By
making these settings configurable, we allow other projects to define
their own worktree-specific reference namespaces too.

The corresponding main repo might hide "refs/worktrees/*" but leave its
refs/bisect namespace exposed in the usual place.

"git prune" would see the whole namespace as it really is so that it can
compute reachability correctly.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu