Re: "git-send-pack"

Linus Torvalds wrote:

On Fri, 1 Jul 2005, H. Peter Anvin wrote:

quoted

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