Re: What's in git.git (stable)

[Linus Torvalds <torvalds@linux-foundation.org>]

On Fri, 27 Apr 2007, Andy Parkins wrote:
> 
> Let's be really, really sure.  I'm not sure a big enough fuss has been made of 
> the fact that this is a change of repository format.  Before this you could 
> pretty much access any repository with any version.

I'm personally really really sure. The whole point of subprojects (at 
least the way _I_ envisioned them) was to have them point to objects 
outside the same repository, so it's more than just an implementation 
detail, it's very much design.

And yes, of course we could have made it point to a blob inside the 
superproject, and have that blob then contain a SHA1 that old versions of 
git wouldn't have known to follow. But that would have been pretty hacky, 
and old versions of git would _still_ have had trouble with the new 
feature: at a minimum, git-fsck would always complain about the invalid 
mode (and things like "git diff" would too - I think it used to just die 
on unknown modes).

The "git-fsck/diff not working" thing might be seen as something that 
isn't important on the server side, but I think it ends up being critial, 
both for gitweb, and simply because I'd expect server side to want to 
verify the projects they export too. So I do think you'd want to have a 
recent git to support recent featurs.

So I think it boils down to: 
 - old git versions will obviously happily continue to  export all normal 
   repositories (including the submodules themselves).
 - but the actual supermodule support for embedding those submodules 
   really is a fundamentally new linkage, and if you want to use 
   supermodules, you have to have a recent enough git. Even if it's just 
   exporting them.
 - with 1.5.2, git will be good enough to _serve_ stuff, even if it might 
   not be very usable for the client-side operations. So especially since 
   there won't be a whole lot of users (due to the client limitations), I 
   think it's fine to expect a "sufficiently capable" git version if you 
   start serving subproject content.

But, yeah, this is just my personal view of sub/superproject support, and 
I've never actually _used_ it myself apart from my small test-repo thing.

		Linus