Re: [PATCH 07/16] git-read-tree: take --submodules option
- From
- Sven Verdoolaege <skimo@kotnet.org>
- Date
- May 24, 2007, 18:45 UTC
- Message-ID
- <20070524184549.GW942MdfPADPa@greensroom.kotnet.org>
- In-Reply-To
- <7viraixeme.fsf@assigned-by-dhcp.cox.net>
On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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 ?
Show 8 quoted lines
> (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?
Show 9 quoted lines
> (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