Re: [RFC] Submodules in GIT
- From
- Torgil Svensson <torgil.svensson@gmail.com>
- Date
- Dec 16, 2006, 15:38 UTC
- Message-ID
- <e7bda7770612160738w68a47790vef922804efd56c76@mail.gmail.com>
- In-Reply-To
- <e7bda7770612160705l61d1f350n70a8ba91754491c9@mail.gmail.com>
On 12/16/06, Torgil Svensson <torgil.svensson@gmail.com> wrote:
Show 10 quoted lines
> On 12/16/06, Jakub Narebski <jnareb@gmail.com> wrote: > > All fine, but this does not and I think cannot protect us from the > > fact that we can have <sha1 of tree/blob> which doesn't match > > <sha1 of commit>. > > True, that will be a real problem. Unless we have a bug in git, do you > see a scenario in which this is likely to happen? > > I also want a sparse/partial checkout but I don't want > the full submodule path.
This might not be as problematic as we think. If we do the same sparse/partial checkout (what's the definition here?) with the <sha1 of tree/blob> as we do with the only <sha1 of commit> case and consider the <sha1 of tree/blob> to be a _local_ (to the super-project) shortcut. Then we only track the submodules using the commit - local conflicts are easier to handle, git would refuse to commit a <sha1 of tree/blob> not present in the commit tree.
We might even consider two object types: module: <sha1 of commit> name link: <sha1 of commit> <sha1 of tree/blob> name