Re: "git-send-pack"

From: H. Peter Anvin <hpa@zytor.com>
Date: Jul 2, 2005, 04:29 UTC
Message-ID: <42C61818.30109@zytor.com>
In-Reply-To: <Pine.LNX.4.58.0507012119360.3019@ppc970.osdl.org>

Linus Torvalds wrote:

Show 16 quoted lines

> 
> On Fri, 1 Jul 2005, H. Peter Anvin wrote:
> 
>>Any reason not to simply append objects to an existing packfile?
> 
> 
> What happens when somebody screws up in the middle?
> 
> The one thing I care about more than anything else is consistency. We are 
> careful about writing objects in the right order, and we can re-create the 
> state from the originator etc. But if we start appending stuff and 
> something goes wrong in the middle, I'm just not going to touch it. A 
> "truncate and hope for the best" algorithm? 
> 
> Besides, the result is not a valid git archive any more. 
>

It's a log. It's a standard technique to append entries to a log. The requirements for this to always be consistent is that a) it's possible to know when the entry/entries at the end are inconsistent and b) it's always possible to roll back the log to a consistent state.

This is normally done with commit records (write data - fdatasync - write commit record - fdatasync), but in the case of git, the commit record isn't required because each git record is self-validating. This is an incredibly powerful property.

If the log is written in topological sort order, then even a truncated log file is a valid (subset) git object store.

	-hpa