git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/8] builtin-clone

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Apr 18, 2008, 00:56 UTC
Message-ID
<alpine.LNX.1.00.0804172052300.19665@iabervon.org>
In-Reply-To
<200804180250.48544.johan@herland.net>
On Fri, 18 Apr 2008, Johan Herland wrote:
Show 6 quoted lines
> 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.

Show 7 quoted lines
> > 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.

Show 23 quoted lines
>   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*
Previous: Johan HerlandNext: Johan Herland
Message 3 of 4 in “builtin-clone”
  1. 0/8 builtin-cloneDaniel Barkalow, Apr 17, 2008
  2. Johan HerlandApr 18, 2008
  3. Daniel BarkalowApr 18, 2008
  4. Johan HerlandApr 18, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.