Shawn Pearce wrote:
- Higher level projects should drive subprojects.
Higher level projects tend to be composed of specific revisions or
specific generations of subprojects.
Part of the content of the higher level project is just what
those subproject specifications are and how those subprojects
should appear in a working directory.
I used the term "generation of subprojects" as not everyone wants
to bind their root project to a specific revision of a subproject.
Indeed that may not be entirely practical. Instead just a particular
lineage of development (e.g. "Version 1.0" vs. "Version 1.2")
may be all that is needed.
Does it not make sense that a commit of the higher level project should
include the contents of its subprojects at that particular moment in time?
e.g. using the previous example of a kernel, apache, glibc, etc
You may track the subprojects using whatever scm applies to THAT
subproject. But when you want to record the state of the entire project,
you want to include the state of the subprojects. So, your super-project
commit would actually recurse down into the working directories of the
subprojects and record the state/contents of each file that makes up
each of the subprojects.
So, if someone is tracking the overall project, and they do a pull of
v1.1 (tag), they will see exactly what v1.1 looked like in your repo.
What this makes me think is that it might be useful to have a mechanism
for recalculating the tree-ish of a subdirectory and finding an
associated commit, for the case where a subproject is also managed by git.
i.e. given a super-project in this state, and knowing that this
subproject is managed by git, which revision of the subproject are we
talking about, and can we find a commit that matches this tree-ish?
(assuming we have the history of the subproject available, of course)
Regards,
Rogan
-
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