Re: [RFC] Submodules in GIT
- From
- Torgil Svensson <torgil.svensson@gmail.com>
- Date
- Dec 16, 2006, 15:05 UTC
- Message-ID
- <e7bda7770612160705l61d1f350n70a8ba91754491c9@mail.gmail.com>
- In-Reply-To
- <em0fpq$45b$1@sea.gmane.org>
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 think it would be better to have sparse/partial checkout first. > But that is just my idea. Because with <sha1 of tree/blob> which > is not sha1 of commit tree you might loose (I think) the ability > to merge, for example your changes to submodule with upstream.
That's correct. I also want a sparse/partial checkout but I don't want the full submodule path. I'm also perfectly fine (for my current use-cases) with not being able to merge upstream unless we're tracking the commit tree (here, we might not want to specify the tree SHA1).
I'm not trying to impose a technically fragile solution here [I don't believe it is, but I'm not the most competent to say that either], I'm trying to find solutions for my use cases and I had problems adapting them to the current suggestion.
Show 10 quoted lines
> > 3. Super-module development independent of submodules - If we have the > > tree/blob-object with all it contents in the database many > > git-operations can act as the link (commit) wasn't there since we have > > access to all relevant data to work with. This makes it easy to clone > > the super-project and work on it seamlessly without having to care > > about submodules or mapping up submodule repository's (unless you want > > to modify the links or the data underneath it of course). > > This is I think irrelevant to the fact if we have only <sha1 of commit>, > or link object and also <sha1 of tree/blob>