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

[Junio C Hamano <gitster@pobox.com>]

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.