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

Martin Waitz [off-list ref] writes:

Now, how to go on?
The next thing we need is a real checkout & merge support -- but that
is not that hard.

As git.git is the project that everybody who is interested in
making the feature to materialize fetches, looks at and works on
anyway, once the support at the plumbing level is complete, an
obvious thing to do is to use it in git.git tree itself.

For example, I would like to eventually be able to remove
git-gui/ subdirectory and bind git-gui.git as a subproject.
Another possibility that is probably of a smaller impact is to
bind what is known as 'todo' branch at Meta/ directory, as that
is where I have the branch checked out in my worktree.  People
who are not interested in what are in 'todo' would not mind
having an empty directory there in their checkout, and
interested ones can use the same layout as I do.

Making git.git the first guinea pig has a unique bootstrapping
problem involved, however.  These kind of changes in git.git
itself has to wait at least until what we have in 'next' today
is in everybody's hands.  Otherwise, people who want to use git
for their real work need to first grab a tarball snapshot that
has the plumbing subproject support, and then update to
'master', because we are still too fast moving for any distro
binary packaged version to be satisfactory solution for people
who want to have all the bells and whistles.  Also, I cannot
have subproject in git.git until kernel.org starts running git
with subproject support -- otherwise nobody can clone or pull
from git.git X-<.

If there was a project of lessor importance that can afford to
say "if you want to track this project, you have to use git from
'next', which has not yet been officially released, but we are a
small closely knit group and we can live with this limitation",
it would be easier, but that would not be as effective guinea
pig as git.git itself would be.

Eating our own dog food is how git has evolved since its early
days.  There was no Porcelain to speak of back then; Linus gave
a recipe for keeping track of your work using 'update-index',
'write-tree', 'commit-tree' and 'echo' (we did not even have
'update-ref' to advance the tip of the branch; instead we did
"commit=$(commit-tree) && echo $commit >.git/HEAD"), and people
first followed that recipe, and later wrote a set of thin shell
wrappers around that recipe.

Then we need to think about how to handle the submodule object
database, e.g. when fetching.

With the clear separation of connectivity rules between modules,
I do not think this is an issue at all.

On 4/20/07, Junio C Hamano [off-list ref] wrote:

Making git.git the first guinea pig has a unique bootstrapping
problem involved, however.  These kind of changes in git.git
itself has to wait at least until what we have in 'next' today
is in everybody's hands.

Have you any plans as to when that should begin to happen?
We can warn user if he tries to add a subproject until
porcelain support can be considered usable. It certainly
wont be a problem for early adopters, they know what they're
doing, and an accidental git add of a directory (which by accident
is a git repo all by itself) does not go unnoticed.
Or even disallow it by default (unset dir_struct:dir_links), and
give git add/update-index an option to allow them. We can
reconsider the default later.

On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:

Making git.git the first guinea pig has a unique bootstrapping
problem involved, however.  These kind of changes in git.git
itself has to wait at least until what we have in 'next' today
is in everybody's hands.  Otherwise, people who want to use git
for their real work need to first grab a tarball snapshot that
has the plumbing subproject support, and then update to
'master', because we are still too fast moving for any distro
binary packaged version to be satisfactory solution for people
who want to have all the bells and whistles.  Also, I cannot
have subproject in git.git until kernel.org starts running git
with subproject support -- otherwise nobody can clone or pull
from git.git X-<.

The bootstrapping issue could be fixed by having a separate
git-subproject.git on kernel.org.

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).

	Sam

hoi :)

On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:

On Fri, Apr 20, 2007 at 04:14:01AM -0700, Junio C Hamano wrote:

quoted

Making git.git the first guinea pig has a unique bootstrapping
problem involved, however.  These kind of changes in git.git
itself has to wait at least until what we have in 'next' today
is in everybody's hands.  Otherwise, people who want to use git
for their real work need to first grab a tarball snapshot that
has the plumbing subproject support, and then update to
'master', because we are still too fast moving for any distro
binary packaged version to be satisfactory solution for people
who want to have all the bells and whistles.  Also, I cannot
have subproject in git.git until kernel.org starts running git
with subproject support -- otherwise nobody can clone or pull
from git.git X-<.

The bootstrapping issue could be fixed by having a separate
git-subproject.git on kernel.org.

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.
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.

-- 
Martin Waitz

On Sat, 21 Apr 2007, Martin Waitz wrote:

On Fri, Apr 20, 2007 at 09:31:42PM +0200, Sam Ravnborg wrote:

quoted

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