Re: [PATCH 0/2] Support for packs in HTTP
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Jul 11, 2005, 00:34 UTC
- Message-ID
- <Pine.LNX.4.58.0507101731330.17536@g5.osdl.org>
- In-Reply-To
- <Pine.LNX.4.21.0507101959410.30848-100000@iabervon.org>
On Sun, 10 Jul 2005, Daniel Barkalow wrote:
Show 21 quoted lines
> On Sun, 10 Jul 2005, Linus Torvalds wrote:
> >
> > Well, regardless, we want to be able to specify which directory to write
> > them to. We don't necessarily want to write them to the current working
> > directory, nor do we want to write them to their eventual destination in
> > .git/objects/pack.
> >
> > In fact, the main current user ("git repack") really wants to write them
> > to a temporary file, and one that isn't even called "pack-xxx", since it
> > ends up doing cleanup with
> >
> > rm -f .tmp-pack-*
> >
> > in case a previous re-pack was interrupted (in which case it simply cannor
> > know what the exact name was supposed to be).
> >
> > So the "basename" ends up being necessary and meaningful regardless. We do
> > _not_ want to remove that capability.
>
> Shouldn't we do the same thing we do with object files? I don't see any
> difference in desired behavior.Well, the main difference is that pack-files can be used for many things.
For example, a web interface for getting a pack-file between two releases: say you knew you had version xyzzy, and you want to get version xyzzy+1, you could do that through webgit some way even with a "stupid" interface. Kay already had some patch to generate pack-files for something.
The point being that pack-files are _not_ like objects. Pack-files are meant for communication. Having them in .git/objects/pack is just one special case.
> Why not checksum it in a predictable order, either that of the pack file > or the index? We do care that it's something verifiable, so that people > can't cause intentional collisions (for a DoS) just by naming their packs > after existing packs that users might not have downloaded yet.
We could sha1-sum the "sorted by SHA1" list, I guess.
Linus