Re: [PATCH 0/8] builtin-clone

[Daniel Barkalow <barkalow@iabervon.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2388 bytes --]

On Fri, 18 Apr 2008, Johan Herland wrote:

> On Friday 18 April 2008, Daniel Barkalow wrote:
> > This is my latest version, rebased approximately on current master (or 
> > recent maint, I guess). It's missing all of Johan's stuff, which is tests 
> > for stuff I've fixed
> 
> Does this mean you no longer need the tests, or that you want me to resend?

I have them, but my patch-sending process isn't set up for sending other 
people's patches without forging their email, and I wanted to get this 
series out, and they're not critical, so I skipped them for now.

> > and (after this series) a series to make the clone generate packed refs.
> 
> I'll resend the series once your work has settled down and landed in "next".
> 
> BTW, I noticed in your repo (at iabervon.org) that you put "if (0)" around
> the code generating packed-refs (using the old one instead), and added the
> following note to the commit message:

It was really mostly that the version I have in there doesn't pass the 
tests, due to not having the thing to filter packed refs.

>   I made this compile-time configurable because I'm not sure we want to
>   pack unconditionally.
> 
> We should probably figure out the right thing to do here. AFAICS,
> compile-time configurability is only a temporary measure, and we basically
> have to choose between:
> 
> 1. Add a command-line option (and config variable?) for controlling
>    whether "git clone" generates packed refs.
> 
> 2. Make "git clone" unconditionally generate packed refs.
> 
> Currently, I'm leaning towards (2), since I don't think there's enough
> drawbacks with generating packed-refs to justify adding a command-line
> option. AFAICS, the only drawback is that reflogs aren't
> created/initialized on clone, but I got the feeling that this was not
> particularly important. Quoting Junio from an earlier thread:
> 
>   Not writing reflogs is a _different_ behaviour from the previous, but I
>   suspect it might even be an improvement.  When you have 1000 remote
>   branches, probably most of them are not even active.
> 
> If there are good arguments for going with (1), I'd love to hear them.

I think it's fine, actually (now that you've not test corrections that 
work for it); but I'd like to have builtin-clone land without any changes 
in behaviour, and then get this sort of improvement.

	-Daniel
*This .sig left intentionally blank*