Re: .gitlink for Summer of Code

[Daniel Barkalow <barkalow@iabervon.org>]

On Tue, 27 Mar 2007, Linus Torvalds wrote:

> On Tue, 27 Mar 2007, Daniel Barkalow wrote:
> > 
> > Is it fair to say that subproject support means that there's a use case 
> > where everybody will need shallow clones? And that it points out natural 
> > triggers for shallowness?
> 
> No.
> 
> I personally don't believe in shallow clones. And I *certainly* don't 
> believe that it has anything to do with subprojects. So people may want 
> shallow clones, but it's at least independent of the issue of submodules.
> 
> With subprojects, it's not that you don't want the history. It's just that 
> you don't want the history for *all* projects. Most people care about a 
> very small subset.

Are you talking about submodule history, or submodule state? If they care 
about any state but not the corresponding history, they need to do a 
shallow clone of the subproject, right?

Or are you assuming that people only want to have every subproject either 
there with full history or entirely absent?

I think that one common thing would be to care about the sequence of linux 
kernel snapshots selected by openembedded in their commits, without caring 
about the linux kernel history in between those snapshots. And they 
probably even want to bisect the superproject (still without getting into 
kernel versions that were never in superproject commits), so they can 
track down what caused their PDA to stop booting, where it's not clear 
which program is even responsible. Maybe once the bug is down to a single 
superproject commit, they'd want the history for the responsible 
subproject.

In any case, I think that the superproject object database needs to keep 
track of where references came from (e.g., if you pull somebody's 
superproject commit, and the point of that commit is to use a 
custom-modified subproject commit, that subproject commit must come from 
the same person, and you need to be able to fetch it correctly after the 
fact if you don't get it immediately, even if you've personally forgotten 
the URL).

> (The exception, of course, is when the superproject simply isn't that big, 
> and only has a couple of subprojects. In git, for example, the xdiff stuff 
> could be a subproject if you wanted to do it that way. But then, the 
> subproject isn't a size issue, it's purely an organizational thing, and 
> there is no argument for/against shallowness there either).

Of course. And to make this use case also viable, it's probably necessary 
to be able to tell git to fetch these subprojects automatically, because 
you'll be sad if you leave for a long plane trip with the latest git but 
not the xdiff it uses. (Clearly an application for .gitattributes, but 
that'd be extra fun to implement.)

	-Daniel
*This .sig left intentionally blank*