Re: [PATCH 1/2] clone: Fix error message for reference repository

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 8, 2013, 15:30 UTC
Message-ID: <7vip3xyr8c.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130408145749.GJ27178@pug.qqx.org>

Aaron Schrab <aaron@schrab.com> writes:

Show 11 quoted lines

> At 06:58 -0700 08 Apr 2013, Junio C Hamano <gitster@pobox.com> wrote:
>>I do agree that it would be nice to dereference .git gitfile when we
>>deal with --reference argument, but you do not want to use in-tree
>>repository of a submodule working tree.  What happens when you have
>>to check out a version of the containing superproject that did not
>>have the submodule you are borrowing from?  The directory will
>>disappear, leaving the borrowing repository still pointing at it
>>with its .git/objects/info/alternates file, no?
>
> No, submodule directories don't get removed when you checkout a
> version which didn't contain that submodule.

In the old world order, we did not use .git gitfile.

The version of the superproject had a submodule at dirA/ and dirA/.git used to be a real directory. "clone --reference /path/to/super/dirA/.git" can borrow objects from there, and will write /path/to/super/dirA/.git/objects (which is a real object store) to the resulting repository's objects/info/alternates.

You switch to a version of the superproject with a plain file at dirA/ or there is nothing at dirA. The checkout will fail and you need to manually rectify the situation [*1*], but after that is done, you do not have any repository at /path/to/super/dirA/.git anymore.

That was the reason why I recommended against the practice.

In the new world order, we use dirA/.git gitfile.

"clone --reference /path/to/super/dirA/.git" does not anticipate .git could be a gitfile, but it can be fixed to dereference it and point at "/path/to/super/.git/modules/moduleA", which will stay there across branch switching at the supermodule level.

"clone" has to store /path/to/super/.git/modules/moduleA in $GIT_DIR/objects/info/alternates of the new repository by dereferencing the value given to --reference. By doing so, what is in the working tree of the superproject would not matter at the time of access in the new repository.

So you are right that we do not remove in the new world order, but then --reference can be given to point at the real location ;-)

[Footnote]

*1* ... for which fundamental fix was made to use dirA/.git gitfile in the submodule working tree in the new world order.