Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> writes:
> If a .git file contains
>
> gitsuper: <path>
> gitdir: <id>
>
> then we set GIT_SUPER_DIR to <path> and GIT_DIR to
> $GIT_SUPER_DIR/repos/<id>.
I initially thought: "what is with that complexity? isn't it just
the matter of replacing 'gitdir: <path>' with 'gitsuper: <path>'
stored in the file .git???"
Until I realized that there is nowhere to keep per-workdir data if
we only had .git as a pointer, and that is why you have that <id>
thing. It would have helped me avoid that confusion if the above
description was followed by:
The latter, $GIT_SUPER_DIR/repos/<id>, is a directory,
underneath which per-work-dir items like index, HEAD, logs/HEAD
(what else?) reside.
or something like that. And $GIT_SUPER_DIR/repos/*/HEAD, especially
when they are detached, plus $GIT_SUPER_DIR/repos/*/index, will work
as the starting point of object reachability scanning when running
repack, fsck, etc.
A few more random thoughts...
- Reusing "gitdir:" for this purpose is not advisable; use a
different name. This <id> is used to identify a workdir, so
perhaps "gitworkdir: <id>" might be a better name;
- Do we want to record where the working tree directory is in
$GIT_SUPER_DIR/repos/<id> somewhere? Would it help to have such
a record?
- How would this interact with core.worktree in .git/config of that
"super" repository?
--
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