Re: What's cooking in git.git (topics)

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

On Sat, 21 Apr 2007, Martin Waitz wrote:
> On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:
> > 
> > But I see no easy solution for the requireent for kernel.org to
> > a new git (and I doubt kernel.org sysadmin is too keen to
> > update to a next-based git).
> 
> Well, it only needs to be new enough to understand enough of
> submodules so that it can play the server part.

Yes. I don't think kernel.org itself really needs more than already exists 
in 'next': it needs the ability to *serve* projects (and that means doing 
the tree traversal properly and know to stop traversing at gitlink 
entries), but kernel.org itself wouldn't actually need any of the 
porcelain at all. The porcelain would all be used on the client sides.

> So once we are in that part to be stable we can merge it to master,
> so that kernel.org can use it.
> Full submodule support should then mature until the next major version
> after which git.git could use it itself.

Yes. I *think* that the gitlink stuff in 'next' is ready to be merged, if 
only because (a) there really hasn't been any disagreement about it (yeah, 
partly probably simply because it was me writing the patches, but I think 
largely because the patches simply were pretty clean!) and (b) there 
aren't any real downsides either, since it won't actually affect any 
non-gitlink use.

So there's certainly the *possible* downside that the whole approach is 
broken and won't work, and merging something broken is pointless. However, 
we've had people thinking about this for quite so time, and I don't think 
anybody seriously believes that it's not a fairly straightforward 
(although probably time-consuming and painful) thing to do all the 
porcelain stuff and it will "just work". So it's _possible_ that there is 
some roadblock that everybody has just ignored, but that just doesn't seem 
very likely.

So it could stay in 'next' until we have everything else in place too, and
the argument for getting it into master literally boils down to the fact 
that it's probably already in a good enough shape for the server side 
(even if the client side is obviously totally missing, and we may find 
*bugs* that are just hiding because it's not used very actively as a 
result). 

I don't really have a huge strong personal feeling either way. I've not 
thought about the patches lately, partly because I'm just fairly happy 
with the core, and partly because I'm just waiting for somebody else to 
start working on it, and then I'll happily jump in and fix any issues that 
come up.

So I would kind of prefer to get it merged sooner rather than later, but 
it's not a huge deal for me - what's more important is probably that 
somebody else rolls up his sleeves and gets dirty with it too ;)

			Linus