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

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 03.01.2012 19:27, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
>> Am 29.12.2011 23:40, schrieb Junio C Hamano:
>>> I further wonder if we can get away without using separate-git-dir option
>>> in this codepath, though. IOW using
>>>
>>>         git clone $quiet -bare ${reference:+"$reference"} "$url" "$gitdir"
>>>
>>> might be a better solution.
>>
>> A quick test shows that using a bare repo won't fly because without the
>> core.worktree setting commands that operate on the work tree can't be
>> run anymore inside submodules (starting with the initial checkout). 
> 
> Probably the right thing to do would be to restructure the flow as I
> suggested, i.e.
> 
> 	if we do not have it yet
>         then
>         	git clone --bare ...
> 	fi
> 	# now we have it, make sure they are correct
> 	git config core.bare false

Ah, I forgot to set core.bare to false when trying this. But even then
a dozen tests fail, no matter if I set core.worktree or not. A cursory
glance indicates problems with branches ... I'll have to dig deeper
here.

> 	git config core.worktree $there

Please see below.

>         echo "gitdir: $here" >$there/.git
> 
>> Yes, and the core.worktree setting also contains an absolute path. So
>> we must either make that relative too and rewrite it on every "git
>> submodule add" to record the possibly changed path there or make the
>> bare clone work with a work tree (which sounds a bit strange ;-).
> 
> Update of core.worktree has to be done regardless of the absolute/relative
> differences anyway, no?

Not if we would implement a "if no worktree is set but we came here via
a gitfile, then take the directory the gitfile was found in as worktree"
heuristic. And that heuristic looks quite sane to me, as a gitfile can
only be found in a work tree, or am I missing something obvious here?