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

[Junio C Hamano <junkio@cox.net>]

Martin Waitz <tali@admingilde.org> 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.