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

Re: [ANNOUNCEMENT] /Arch/ embraces `git'

From
Petr Baudis <pasky@ucw.cz>
Date
Apr 20, 2005, 21:31 UTC
Message-ID
<20050420213114.GF19112@pasky.ji.cz>
In-Reply-To
<200504201000.DAA04988@emf.net>

Dear diary, on Wed, Apr 20, 2005 at 12:00:36PM CEST, I got a letter where Tom Lord <lord@emf.net> told me that...

> >From the /Arch/ perspective: `git' technology will form the
> basis of a new archive/revlib/cache format and the basis
> of new network transports.

I think one thing git's objects database is not very well suited for are network transports. You want to have something smart doing the transports, comparing trees so that it can do some delta compression; that could probably reduce the amount of data needed to be sent significantly.

> >From the `git' perspective, /Arch/ will replace the lame "directory
> cache" component of `git' with a proper revision control system.
I'm not sure if you fully grasped the git's philosophy yet. The
"directory cache" component is not by itself any revision control system
- it is merely a staging area for any revision system on top of it (IOW:
subordinate, not competitor).
Show 7 quoted lines
> I started here:
> 
>    http://www.seyza.com/=clients/linus/tree/index.html
> 
> and for those interested in `git'-theory, a good place to start is
> 
>    http://www.seyza.com/=clients/linus/tree/src/liblob/index.html

These pages are surely very nice, unfortunately I have to enjoy them only from the "HTML source" view. The HTML seems completely broken, containing unterminated comments like "<!-- BEGIN the main body>". :-(

You didn't go into surely interesting details regarding what will you be fixing regarding ancestry graphs.

Also, I have some concerns about your naming scheme. First, why do you include the size in the filename? Second, with ..../..../ you are _seriously_ worse off than with ../. The first will put 1/256 of project files to each directory, where with the second you will have 1/4294967296 of project files per directory. I think the point of directory is that it is a container grouping certain files in a certain way; in the objects database it is done purely for performance (and compatibility, to a degree) reasons, but your way it will have worse performance characteristics at least until the project accumulates 4294967296 files in the database.

Kind regards,
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
Previous: Edésio Costa e SilvaNext: C. Scott Ananian
Message 19 of 23 in “[ANNOUNCEMENT] /Arch/ embraces `git'”
  1. Tom LordApr 20, 2005
  2. Miles BaderApr 20, 2005
  3. duchier@ps.uni-sb.deApr 20, 2005
  4. Tomas MrazApr 20, 2005
  5. Denys DuchierApr 21, 2005
  6. Tomas MrazApr 21, 2005
  7. duchier@ps.uni-sb.deApr 21, 2005
  8. Tomas MrazApr 20, 2005
  9. Tom LordApr 21, 2005
  10. Tom LordApr 21, 2005
  11. Tom LordApr 20, 2005
  12. Denys DuchierApr 21, 2005
  13. Tom LordApr 21, 2005
  14. Tomas MrazApr 21, 2005
  15. Tom LordApr 21, 2005
  16. Tom LordApr 21, 2005
  17. Linus TorvaldsApr 22, 2005
  18. Edésio Costa e SilvaApr 22, 2005
  19. Petr BaudisApr 20, 2005
  20. C. Scott AnanianApr 20, 2005
  21. chunking (Re: [ANNOUNCEMENT] /Arch/ embraces `git')Linus Torvalds, Apr 20, 2005
  22. C. Scott AnanianApr 20, 2005
  23. blowing chunks (quick update)C. Scott Ananian, Apr 22, 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.