At 08:30 -0700 08 Apr 2013, Junio C Hamano <gits...@pobox.com> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
