Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 02:17:27PM +0100, Johannes Schindelin wrote:
> > On Thu, 24 May 2007, Sven Verdoolaege wrote:
> > > I suppose we could just set it to 0.
> > > I also don't think the URL should be associated to a ref.
> >
> > It does not need to be.
> >
> > But then, it is sort of a "subref": You could just clone the submodule in
> > its own right, correct?
>
> Exactly, but the information we want is not associated to any
> particular revision of the submodule. It just points to the repo.
> It's also not associated with any revision of the supermodule.
> That information should go in a tracked .gitmodules file.
It is not that expensive to just give the SHA-1 with the URL, and to
introduce a new namespace, say
3f... submodule/path^{URL:blablub}
to say that the submodule which is connected in "HEAD:path" is available
with the URL "blablub" and just so happens to be at commit "3f..." at the
moment. Heck, you can even use this instead of expensive fetches to verify
up-to-date, and even more, you can make sure that you are as up-to-date as
the remote supermodule.
But then, I do not care about that deeply. Like I said, I haven't followed
the discussions, but I really do not understand why an information as
essential to a superproject is not contained in something like
HEAD:.gitmodules. Git does not have to take it from there, it can still
continue to take it from a local config in .git/, but .gitmodules can live
in the tree happily, for the pleasure of the tools (if only to initialise
the first version of the local config after clone).
Without some very intrusive surgery into the transport code of Git, in 22
patches, which I am not at all comfortable with.
Ciao,
Dscho
-
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
