Sven Verdoolaege <skimo@xxxxxxxxxx> writes:
> 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 ?
You could do that -- I consider that a minor detail in the
implementation.
>> (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?
I meant a bare clone without separate remotes.
The counter-proposal outline essentially says, for the sake of
simplicity, "nuke existing subproject directory whenever we need
to replace it with something else, and reclone a new/replacement
subproject directory every time we need to check it out, after
making sure nothing is lost".
Except that having this intermediate repository (a) helps making
such a re-clone extremely cheap "git clone -l -s -n", and (b)
provides with a place to hold locally committed changes that are
not pushed back to the true upstream (you may _never_ push it
back in the first place).
>> (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?
If you are disconnected, you obviously cannot afford to update
(2) every time you switch branches in the superproject, and even
if you are connected, updating (2) would not be needed most of
the time if what you are doing is switching superproject
branches, as long as your last superproject fetch is not very
much more recent than your last subproject fetch.
If we were to follow the outline in the counter-proposal, I'd
imagine that update of (2) can happen at any time. It could be
part of "git fetch" in superprojects, of lazily done when we
need to checkout a new revision for a particular subproject, but
only if the last time you fetched superproject is more recent
than the time you updated (2) for the subproject last time.
Or something like that. I consider that also a minor detail in
the implementation.
-
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
