Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> Am 29.12.2011 23:40, schrieb Junio C Hamano:
>> Antony Male <antony.male@xxxxxxxxx> writes:
>> 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
git config core.worktree $there
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?
The first version of the superproject you trigger module_clone for
submodule $name may happen to have it at $path, module_clone notices that
you do not have it, and the initial "clone --separate-git-dir" will set
the core.worktree to $superproject/$path. Nobody will update it after
that, even when we check out different version of superproject that has
the same submodule $name at a different location in the superproject.
--
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