On Tue, 26 Feb 2008, Johan Herland wrote:

quoted text
> Other than the failing tests, it seems to work fairly well. I've been
> playing around with it for a few minutes, and on a test repo I have with
> 1001 branches and 10000 tags, it cuts down the runtime of a local git-clone
> from 25 seconds to ~1.5 seconds. (simply by eliminating the overhead of
> invoking git-update-ref for every single ref) :)

Good to hear. A certain amount of the point is performance, and I've only 
got relatively simple repositories on Linux to test with, where everything 
is too fast to tell anyway.

quoted text
> I've tried to test this by diffing a cloned repo against an equivalent
> clone done by the old script. Below I pasted in a few immediate fixes I
> found. With these fixes, the only remaining diff between the clones is
> that refs/remotes/origin/HEAD used to be a symbolic ref (with no reflog),
> but is now a "regular" ref (with reflog).

I think that's just a call to the wrong function (and a lack of very very 
explicit documentation).

quoted text
> The fixes are, in order of importance:
> - Call git_config(git_default_config) in order to properly set up
>   user.name and user.email for reflogs (This BREAKS test #9 in
>   t1020-subdirectory.sh. Have yet to figure out why)

I should have read email last night; I could have identified a bunch of 
the odd errors for you, but you've figured most of them out by now.

I need to look into the config system further; things should be configured 
such that the local config is in the new directory and the global config 
is unchanged. If no environment variable is set and pwd is a certain way, 
git_config_set() will write to the wrong file.

quoted text
> - Fix "clone from $repo" reflog messages (using strbufs; something tells
>   me more of this code would benefit from using strbufs)

Most likely. I think Kristian wrote most of this before strbuf existed or 
something of the sort.

quoted text
> - H