Re: CAREFUL! No more delta object support!

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 29, 2005, 21:05 UTC
Message-ID: <Pine.LNX.4.21.0506291644120.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.58.0506291142510.14331@ppc970.osdl.org>

On Wed, 29 Jun 2005, Linus Torvalds wrote:

Show 8 quoted lines

> and you now have moved over _all_ the objects that were referenced in "a",
> but not in "b". Including tags etc. So after that last stage, when you've
> unpacked the objects, the only thing left to do is to make the refs in "b"  
> point to the new references from "a" (which basically boils down to a
> "cp", except it would be good to verify that the refs in "b" still have
> the same values as they did before we did the object push).
> 
> Daniel (or anybody else), interested? Please?

I'll probably get to this over the weekend.

Show 6 quoted lines

> Of course, you can do this one branch at a time, too, if you want to, but
> the above was meant as an example of how you can actually do all the
> branches in one single pack-file, which is a lot more efficient (if you do
> it one branch at a time, you'll quite possible end up transferring objects
> that are reachable in other branches multiple times, while the "all in one
> go" thing will pack each object just once).

It should transfer each only once if you recalculate "refs_in_b" after each push, right? Or is the marking for "--objects ^commit" still not tight wrt object and tree files? I think branch-at-a-time is preferable for the case where the source doesn't want to send quite everything, and the target doesn't necessarily want everything named the same.

> Now, have I actually _tested_ the above? Hell no. But all the heavy 
> lifting should now be done for doing an efficient "git push" that pushes 
> all branches in one go (or one at a time, it's your choice on how you end 
> up using git-rev-list).

The one thing I can think of is whether things will blow up if the target repository has heads that aren't in the source, at which point the source has no clue what to exclude. I.e.:

parent -- new-b
  \
   new-a

If I've moved the head on b forward to new-b, and a wants to push new-a (as a new branch, perhaps), refs_in_b has only new-b, refs_in_a has parent and new-a, and git-rev-list in a can't see that b has parent (and everything upwards of that). You probably just don't want to do this, but I bet that some people will (e.g. projects that synchronize through a shared-owner repository).

	-Daniel
*This .sig left intentionally blank*