Am 03.01.2012 19:27, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@xxxxxx> 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?
--
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