Re: [PATCH] Submodules always use a relative path to gitdir

Phil Hord [off-list ref] writes:

quoted

Again, who said that you are allowed to move the superproject directory in
the first place? I would understand that it might be nicer if it could be
moved but I haven't thought this through thoroughly yet---there may be
other side effects from doing so, other than the relativeness of "gitdir".

Previously it was accepted practice to clone a local repo with rsync.
This method continues to work well even with submodules before
git-files became the norm.  But now it breaks because of the absolute
paths.

You are utterly mistaken.

There are 47 million things you can do to your repository outside of the
control of git, and obviously we do not exhaustively enumerate everything
that ought to work (or not work). Anything that is not explicitly allowed
in the documentation is, ehh, not allowed.

Many such things may happen to work, either by accident or as a natural
consequence of the design. Some things needs adjustments after you do them
without telling git. There is a difference between what is not allowed and
what is explicitly forbidden.

Copying with rsync (or cp for that matter) is one good example. Doing so
will cause the cached stat information in the index and the working tree
files go out of sync, and diff-files will give you false differences after
that. You would adjust to that by running "update-index --refresh". So we
do not say "you are allowed to cp and git will guarantee everything will
work as-is", but it is not explicitly forbidden. As long as you make
necessary adjustments, you can keep using the copied repository.

So, who said you were NOT allowed to move the superproject directory
directory in the first place?

See above.

And the extent of the design of

    echo "gitdir: $there" >.git && git config core.worktree "$(pwd)"

is to work with the locations of these two places as they are set up.
Moving one or the other or both may or may not work without adjusting to
what you did. If you "mv $there $newlocation" (the repository) behind
Git's back, you may need to update .git to point at the new location of
the repository.  If you move your working tree woth "mv", you may need to
update core.worktree to point at the new location of the working tree.
And until you do so things may not work. That is why we do not explicitly
say "you can move them to arbitrary places without telling git and things
will work"---because that is not the case.

This doesn't explain why one path is absolute and one is relative.

Exactly. Because absolute/relative does not come into play as the scope of
the design did not include supporting "moving" one, the other, or both to
arbitrary places without telling git.