git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Apr 27, 2007, 17:11 UTC
Message-ID
<alpine.LFD.0.98.0704271002310.9964@woody.linux-foundation.org>
In-Reply-To
<200704271019.56341.andyparkins@gmail.com>
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
Previous: Andy ParkinsNext: Andy Parkins
Message 9 of 18 in “What's in git.git (stable)”
  1. Junio C HamanoApr 16, 2007
  2. Junio C HamanoApr 18, 2007
  3. Junio C HamanoApr 22, 2007
  4. Junio C HamanoApr 23, 2007
  5. Junio C HamanoApr 27, 2007
  6. Andy ParkinsApr 27, 2007
  7. Nicolas PitreApr 27, 2007
  8. Andy ParkinsApr 27, 2007
  9. Linus TorvaldsApr 27, 2007
  10. Andy ParkinsApr 27, 2007
  11. Linus TorvaldsApr 27, 2007
  12. Junio C HamanoApr 29, 2007
  13. J. Bruce FieldsApr 30, 2007
  14. Junio C HamanoApr 30, 2007
  15. J. Bruce FieldsMay 1, 2007
  16. Junio C HamanoMay 6, 2007
  17. Jakub NarebskiMay 7, 2007
  18. Frank LichtenheldMay 7, 2007

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.