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

> * jc/fetch (Sun Mar 4 15:36:08 2007 -0800) 15 commits
> + .gitignore: add git-fetch--tool
> + builtin-fetch--tool: fix reflog notes.
> + git-fetch: retire update-local-ref which is not used anymore.
> + builtin-fetch--tool: make sure not to overstep ls-remote-result
>   buffer.
> + fetch--tool: fix uninitialized buffer when reading from stdin
> + builtin-fetch--tool: adjust to updated sha1_object_info().
> + git-fetch--tool takes flags before the subcommand.
> + Use stdin reflist passing in git-fetch.sh
> + Use stdin reflist passing in parse-remote
> + Allow fetch--tool to read from stdin
> + git-fetch: rewrite expand_ref_wildcard in C
> + git-fetch: rewrite another shell loop in C
> + git-fetch: move more code into C.
> + git-fetch--tool: start rewriting parts of git-fetch in C.
> + git-fetch: split fetch_main into fetch_dumb and fetch_native
>
> This is a partial C rewrite of heaviest part of git-fetch to
> help fetching between repositories with hundreds of refs.  I do
> not like the way it is split, but it may be a good idea to throw
> it in 'master' as it does not seem to regress anything and see
> if there are other interested people who want to finish the
> rewriting.

> * sb/fetch (Mon Mar 12 19:01:11 2007 -0700) 19 commits
> + git-fetch.sh:append_fetch_head() no longer has a remote_nick
>   argument
> + git-fetch: Split fetch and merge logic
>
> I have a soft spot to anything that claims to be a clean-up, but
> I suspect that the shell loop this series introduces may defeat
> the git-fetch--tool optimization.  Also I think having to base
> the patch on this made Paolo's "dot is special token to mean
> 'git pull' merges from a local branch" needlessly complex (but I
> haven't tried rewriting it myself without these two).  Although
> I merged these to 'next', I am considering to revert them.