Phil Hord <phil.hord@xxxxxxxxx> writes:
>> 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.
--
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