git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] Support for packs in HTTP

From
Daniel Barkalow <barkalow@iabervon.org>
Date
Jul 11, 2005, 03:22 UTC
Message-ID
<Pine.LNX.4.21.0507102253270.30848-100000@iabervon.org>
In-Reply-To
<Pine.LNX.4.58.0507101731330.17536@g5.osdl.org>
On Sun, 10 Jul 2005, Linus Torvalds wrote:
Show 36 quoted lines
> 
> 
> On Sun, 10 Jul 2005, Daniel Barkalow wrote:
> 
> > 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.

Okay, I can see the use for them getting written to arbitrary paths; but I think that it's worth having a canonical location for a pack that's being used by the system (either not having been sent anywhere, or after having been received). Perhaps git-pack-objects should have the base as a optional argument, with a default of the filename in $GIT_DIR/objects/pack and an option for sending just the pack file to stdout? I think that covers everything in order of usefulness, and means that the program deals with any filename that the user doesn't know in advance.

Show 6 quoted lines
> > 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.

That'd be good; then git-http-pull can validate the hash on the index and be sure that a matching pack file from a different location still has the same contents.

	-Daniel
*This .sig left intentionally blank*
Previous: Linus TorvaldsNext: Linus Torvalds
Message 11 of 15 in “Support for packs in HTTP”
  1. 0/2 Support for packs in HTTPDaniel Barkalow, Jul 10, 2005
  2. 1/2 Management of packs not yet installedDaniel Barkalow, Jul 10, 2005
  3. 2/2 Demo support for packs via HTTPDaniel Barkalow, Jul 10, 2005
  4. Darrin ThompsonJul 11, 2005
  5. Daniel BarkalowJul 12, 2005
  6. Darrin ThompsonJul 12, 2005
  7. Junio C HamanoJul 10, 2005
  8. Linus TorvaldsJul 10, 2005
  9. Daniel BarkalowJul 11, 2005
  10. Linus TorvaldsJul 11, 2005
  11. Daniel BarkalowJul 11, 2005
  12. Linus TorvaldsJul 11, 2005
  13. Daniel BarkalowJul 11, 2005
  14. Linus TorvaldsJul 11, 2005
  15. Daniel BarkalowJul 11, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.