On Mon, 11 Jul 2005, Daniel Barkalow wrote:
> On Sun, 10 Jul 2005, Linus Torvalds wrote:
> 
> > 
> > You really _mustn't_ try to create the pack directly to the
> > $GIT_DIR/objects/pack subdirectory - that would make git itself start
> > possibly using that pack before the index is all done, and that would be
> > just wrong and nasty.
> >
> > So you really should _always_ generate the pack somewhere else, and then 
> > move it (pack file first, index file second).
> 
> It's currently fine ignoring index files without corresponding
> pack files (sha1_file.c, line 470).

That doesn't help.

Redgardless of which order you write them (and you _will_ write the 
pack-file first), you'll find that at some point you have both files, but 
one or the other isn't fully written, ie they are unusable.

And yes, you can handle that by always checking the SHA1 of the files when 
you open them, but the fact is, you shouldn't need to, just to use it. 
Checking the SHA1 of the pack-file in particular is very expensive (since 
it's potentially a huge file, and you don't even want to read all of it).

So you could have rules like: pack-file must get populated first, and 
index file must be SHA1-checked by all users.

Or, you could just have a saner rule: create the pack-files somewhere 
else, and move them atomically to the right place. Problem solved.

So that's what I decided the rule is: never ever have a partial file, and 
thus you can by definition use them immediately when you see both files.

But that requires that you write them under another name than the final 
one. And since you want that _anyway_ for other uses, you don't hide that 
inside "git-pack-objects", but you make it an exported interface.

                Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to