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

Aaron Schrab [off-list ref] writes:

At 06:58 -0700 08 Apr 2013, Junio C Hamano [off-list ref] wrote:

quoted

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.

At 08:30 -0700 08 Apr 2013, Junio C Hamano [off-list ref] wrote:

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.

So you're essentially saying you don't want to support using a new-world 
submodule as a reference because using an old-world submodule as such is 
likely to be problematic?  Even though the type of submodule that is 
actually likely to cause problems would currently be accepted as a 
reference repository?  That seems somewhat perverse to me.

Also, nothing in this series is strictly about submodules; that just 
happens to be what I was working with when I noticed the issue.  It 
would apply to any repository created with --separate-git-dir, although 
submodules are likely to be the most common occurrence by far.

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 ;-)

Yes, that's definitely a possibility.  But I think that the location of 
the work tree for a repository is much more likely to come to a user's 
mind than the location of a non-bare repository.  Especially when 
dealing with submodules where the repository location was decided for 
the user, and is somewhat of an implementation detail that the user 
shouldn't need to care about.