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