On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
> How about doing something like this, instead?
>
> (1) superproject .gitmodules (in-tree) and .git/config (local
> repository) use the three-level naming in $gmane/47567.
> Namely, (1a) .gitmodules says which subdirectory has a
> checkout of what project, and names the project in
> logical/abstract terms, not with a URL (e.g. "kernel26");
> (1b) .gitmodules also associates a set of suggested URLs
> for each of the logical/abstract project name; (1c)
> .git/config records which project are of interest.
What about the idea of considering any project that is already
present to be of interest by default ?
> (2) In superproject .git/, we would have a bare repository for
> each project used by the superproject.
>
> .git/subproject/kernel26/{objects,refs,...}
>
> This is created by making a bare clone from the upstream
> URL, decided by the user with the help from suggested URL
> described in the superproject .gitmodules.
Do you mean a "pure" clone, i.e., without a working tree,
but with separate-remotes?
> (4b) It has the same logical/abstract project checked out;
> the commit recorded in the superproject tree may or may not
> be the same as what its HEAD points at. In this case we do
> not have to worry about swapping the git repository at
> kernel-src/ directory, although we would need to check out
> the correct revision, and worry about what to do with any
> local modification (I think the usual "don't lose local
> modification but carry them forward" rule would be Ok in
> this case).
We may also need to fetch from the remote subproject.
Should I do this with a "git fetch" during the checkout as I do now?
skimo
-
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
