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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2012, 18:45 UTC
Message-ID: <7vlipovd4n.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CABURp0pdvf9Eo_pM2UCYUBANOJOGON6pQS-SXuCWQE=s2XNOfQ@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> writes:

Show 9 quoted lines

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