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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2012, 00:11 UTC
Message-ID: <7vlipllmfh.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F0629C6.9010908@web.de>

Jens Lehmann <Jens.Lehmann@web.de> writes:

> So in the long run I suspect we might have to change core git anyways
> to make moving submodules easy for the user (surely "git mv" and maybe
> also the setup and gitfile code). Does that make more sense?

If you need to change "git mv" anyway to help moving submodule checkout, then how gitfile points into .git/modules/ hierarchy of the superproject becomes an implementation detail the end users should not have to care about.

What does "if we reached thru a gitfile, then the working tree is where you found that gitfile" really solve? The way you found that gitfile is by traversing the directory hierarchy upwards from a subdirectory of a working tree of a submodule, and you already know where the top of that working tree is, no?

And the heuristics would not work if somebody goes into the $GIT_DIR/ that governs the submodule as going upwards from there will not hit gitfile, so we would need help from core.worktree anyway. A non-submodule setting that uses gitfile would need to worry about core.worktree, too, so I'd rather avoid loading more heuristics to gitfile handling unless there is a clear advantage for doing so, which I am not really seeing here.

That is not really a "If not" below (i.e. I am not saying it is _not_ OK. I am saying I don't know what the advantage of that approach is), but ...

> If not I'm fine with just setting core.worktree to a relative path in
> the git-submodule.sh script (like I did for the gitfile). And I'll look
> into teaching "git mv" about submodules right after that.

... teaching "git mv" may be a good move, I would think. I do think keeping core.worktree pointing at the right directory is necessary, but I do not see much point in making it a relative path, though.