Re: Change set based shallow clone

From: Junio C Hamano <junkio@cox.net>
Date: Sep 11, 2006, 07:11 UTC
Message-ID: <7vr6yikhdj.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060911060820.GB29368@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

> I think Linus was suggesting the same thing, just not nearly as
> obvious.  He also was looking for ways to not update it frequently.
> But I can't say I'm a fan of negative entries. :-)

I like Linus's suggestion quite a lot actually. It would be a nice little project that needs to touch reasonably well-isolated area of the code, but I suspect it would need a bit more exposure and familiarity to the existing code than somebody who looks at the core code for the first time.

> But at this point I have more on my plate than I have time for.  :-)

You've done quite a lot of work on refs area yourself, so you might want to give somebody else the chance to try first ;-).

> I've got to get that map window code merged against master or next
> (preference Junio?  next touches code I'm touching too but those
> aren't in master yet) for 32 bit offset.

As you know I've shelved the 64-bit offset stuff. My preference is to base it on 106d710b but basing it on 'next' would be fine. Between 106d710b and next there is only one unrelated change to sha1_file.c, which is the hexval[] change that is in 'master'.

I've sent out "What's in" tonight but forgot to talk about plans for topics in "next", so here is an update.

 - These things are probably Ok, and after a bit more testing
   I'd like to push them out to 'master' by my Wednesday:

   - Andy Whitcroft's "send-pack to use git-rev-list --stdin"
   - "git apply" to apply binary without explicit --binary flag;
   - "git diff --binary" to do full-index only for binary patch;
   - "git unpack-objects -r", except it needs a better name
     (perhaps --recover).

 - And these by the end of week:

   - Jeff King's git-runstatus;
   - Frank and Rene's git-archive along with git-daemon change;

 - I am not _so_ comfortable with these quite yet, but plan to
   test it a bit more to gain confidence and decide when to push
   out to 'master' perhaps by the middle of the week:

   - pack-objects --unpacked=this-pack --unpacked=that-pack
   - pack-objects --stdin

> I also want to spend more time on the dictionary packing prototype to
> see if its worth spending even more time on.

So far I liked the per-object-type dictionary conjecture the most, primarily because my gut feeling tells me that it would involve the least amount of hassle in the interoperability area.

But honestly speaking I am not looking forward to a packfile format update at this moment. I'd like things to settle down a bit now, after merging good bits from 'next' to 'master' and declare 1.4.3 first, perhaps by the end of the month.