Re: CAREFUL! No more delta object support!

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Jun 28, 2005, 20:01 UTC
Message-ID: <Pine.LNX.4.21.0506281535340.30848-100000@iabervon.org>
In-Reply-To: <Pine.LNX.4.58.0506281111480.19755@ppc970.osdl.org>

On Tue, 28 Jun 2005, Linus Torvalds wrote:

Show 6 quoted lines

> On Tue, 28 Jun 2005, Linus Torvalds wrote:
> > 
> > I can certainly add an option to git-pack-file that disables writing of
> > the index file, and just writes the pack-file to stdout.
> 
> Done.

What I actually meant was that it would be useful for git-ssh-push to be able to pack stuff as a function call rather than execing an external program, because just sticking git-ssh-push at the end of a pipeline doesn't work if you don't remember what the remote side has.

Show 7 quoted lines

> >						 I'm not sure I
> > want to write the "parse incoming pack-file" thing, but git-unpack-objects
> > comes _reasonably_ close (but right now it seeks around using the index
> > file to resolve deltas, instead of keeping them in memory and resolving
> > them when possible).
> 
> I'm still thinking about this one. I think I'll just do it.

One possibility would be to put a special type tag (like '\0') before the hash, so that the format is more deterministic.

Show 5 quoted lines

> One problem here is that since we don't know how big the incoming
> pack-file will be, in a streaming input environment the receiver needs to
> either make the pack-file reception be the last thing it sees, or it will
> have to live with the fact that "git-unpack-objects" will read some more
> than it needs before it notices that it got it all...

In a completely streaming environment, yes; but the receiving side is the one sending commands, so you don't run into the next thing unless you're overlapping requests. Failing that, we can just keep a 4k buffer of stuff we've already read around; we don't have to worry about reading into something we won't want to read at all.

	-Daniel
*This .sig left intentionally blank*