On 12/16/06, Jakub Narebski <jnareb@xxxxxxxxx> 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.
> 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>
I agree. - 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