Re: [PATCH 07/16] git-read-tree: take --submodules option

From: Junio C Hamano <junkio@cox.net>
Date: May 24, 2007, 18:58 UTC
Message-ID: <7vy7jevyjx.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070524184549.GW942MdfPADPa@greensroom.kotnet.org>

Sven Verdoolaege <skimo@kotnet.org> writes:

Show 14 quoted lines

> 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.

Show 11 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?

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).

Show 12 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?

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.