Nguyễn Thái Ngọc Duy  <> 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
More majordomo info at

Reply via email to