Re: GSoC status report

Hi,

On Fri, 20 Jul 2007, Jakub Narebski wrote:

For my part, I am very pleased with the progress Carlos is making with builtinification. He is quite familiar with the source code by now, and with the style We Do Things Here(tm). Even though _he_ thinks the progress is slow, I do not. The first phase was to get acquainted with the code, and with the techniques to convert shell code into C.

And since Kristian joined into the builtinification process, and since Carlos and Kristian are working together quite nicely, I am even more happy.

FWIW this is the list of scripts that I would like to see converted by the end of the year (feel free to object), ordered by their size:

verify-tag, reset, repack, tag, checkout, rebase, bisect, rebase--interactive, am, commit.

It looks like 'tag' and 'commit' are pretty near to completion, with 'tag' already being in the 'next' branch, and verify-tag will probably follow soon.

The list left out two clusters: 'fetch' related scripts (pull, ls-remote, parse-remote, fetch, clone) and 'merge' related scripts (merge-ours, merge-resolve, merge-stupid, merge-octopus, merge)¹.

Julian and Daniel are working on the fetch front, and the progress is awesome. I especially like the abstraction we have now, so that new transports are much easier to implement. I am even tempted to have a go at 'pushing' to bundles.

Seems like I got the 4 people I wished for the builtin project, in a way ;-)

IMHO 'stash', 'submodule' and 'filter-branch'² are not yet ready to be made builtin.

As for the merge stuff, I consider it too soon, too, especially since "git-merge" is a critical part of core Git _and_ quite long (even if the same arguments would apply to 'commit', too, but Kristian is already at work ;-)

Ciao, Dscho

Footnote 1: I left out merge-one-file, since I have an (untested) builtin in my tree. So there is not really much work to do there, I only have to find some time to research how to test this script properly.

Footnote 2: Sven is working on rewrite-commits, which is somewhat more limited than filter-branch ATM, though faster. As Junio suggested, we can always consider using rewrite-commits as a fast backend to filter-branch, once both rewrite-commits and filter-branch stabilised.