Andy Parkins wrote:
On Thursday 2006 November 30 18:57, Andreas Ericsson wrote:
(agree with everything in your mail)
The only problem I'm seeing atm is that the supermodule somehow has to
mark whatever commits it's using from the submodule inside the submodule
repo so that they effectively become un-prunable, otherwise the
supermodule may some day find itself with a history that it can't restore.
What about submodule/.git/refs/supermodule/commit12345678, where "12345678" is
the hash of the supermodule commit? This gives a convenient route in the
submodule to which commit contains that commit from the submodule; but
doesn't write anything into the submodule repository itself. It's just a tag
with a different intent.
True, but this makes one repo of the submodule special. Let's say you
have this layout
mozilla/.git
mozilla/openssl/.git
mozilla/xlat/.git
Now, we can be reasonably sure that the 'xlat' repo is something the
mozilla core team can push to, or at least we can consider the core repo
owners an official "vendor" of tags for the submodule repo. I'm fairly
certain openssl authors won't be too happy with allowing the thousands
of projects using its code to push tags to its official repo though.
Now that I think about it more, I realize this is completely irrelevant
as the ui can create the tags in the submodule with info only from the
the supermodule, which means the submodule repo will only be special if
it's connected to the supermodule. We just need a command for creating
those tags in the submodule repo so people who use the same submodule
code for several projects can use the alternates mechanism effectively.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
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