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

Martin Waitz <tali@admingilde.org> writes:

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.

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