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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2012, 18:27 UTC
Message-ID: <7vsjjwvdyl.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4F007492.8010909@web.de>

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

Show 12 quoted lines

> Am 29.12.2011 23:40, schrieb Junio C Hamano:
>> Antony Male <antony.male@gmail.com> 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.