Rogan Dawes wrote:
[...]
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)
Some development environments will require that all the (used) code is
imported into the local VCS of choice. But not all environments. For
some development environments, recording the version of the subproject
is sufficient. Assuming it's possible at some future time to get the
state associated with the version.
Also keep in mind, to effectively participate in a project, you will
likely need to use the VCS of the project. So importing everything into
another VCS (Git) will just cause _you_ more work.
-
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