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

Re: [RFC] shallow clone

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jan 31, 2006, 13:31 UTC
Message-ID
<Pine.LNX.4.63.0601311422400.7918@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To
<43DF608C.1060201@hogyros.de>
Hi,
On Tue, 31 Jan 2006, Simon Richter wrote:
> Well, the important thing would be that commands that can work (a merge only
> needs to find the most recent common ancestor, etc) do work, and commands that
> cannot ("log") emit sensible diagnostics.
No it would not.

A commit is a very small object which points (among others) to a tree object.

A tree object corresponds to a directory (that is, it can point to a number of tree and blob objects).

A blob object corresponds to a file (that is, git never parses its contents).

If two separate revisions contain the same file (i.e. same contents), this is not duplicated, but the corresponding tree objects point to the same object.

If you pull, upload-pack will think you have *every* object depending on every ref you have stored.

Say you have three revisions, A -> B -> C, and A and C contain the same file bla.txt, and the client says it has B, the upstream upload-pack assumes you have bla.txt.

> I know far too little about the internal workings for that, [...]
I hope I clarified the important aspect.
Show 5 quoted lines
> > If you now rely on the grafts file to determine what was a cutoff, you may
> > well end up with bogus cutoffs.
> 
> Exactly that was my concern earlier; my database design gut feeling tells me
> that information duplication is not good either, [...]

You only have two choices: you proposed code duplication, and yours truly proposed data duplication.

As is known from good database design: a few redundancies here and there are typically needed for good performance.

Ciao, Dscho

Previous: Simon RichterNext: Simon Richter
Message 9 of 30 in “[RFC] shallow clone”
  1. Junio C HamanoJan 30, 2006
  2. Johannes SchindelinJan 30, 2006
  3. Simon RichterJan 30, 2006
  4. Johannes SchindelinJan 30, 2006
  5. Simon RichterJan 30, 2006
  6. Junio C HamanoJan 30, 2006
  7. Johannes SchindelinJan 31, 2006
  8. Simon RichterJan 31, 2006
  9. Johannes SchindelinJan 31, 2006
  10. Simon RichterJan 31, 2006
  11. Junio C HamanoJan 30, 2006
  12. FranckJan 31, 2006
  13. Junio C HamanoJan 31, 2006
  14. FranckJan 31, 2006
  15. Junio C HamanoJan 30, 2006
  16. Shallow clone: low level machinery.Junio C Hamano, Jan 31, 2006
  17. Johannes SchindelinJan 31, 2006
  18. Junio C HamanoJan 31, 2006
  19. Johannes SchindelinJan 31, 2006
  20. Junio C HamanoJan 31, 2006
  21. Johannes SchindelinFeb 1, 2006
  22. Junio C HamanoFeb 1, 2006
  23. Johannes SchindelinFeb 2, 2006
  24. Junio C HamanoFeb 2, 2006
  25. Johannes SchindelinFeb 2, 2006
  26. Junio C HamanoFeb 2, 2006
  27. Johannes SchindelinJan 31, 2006
  28. Junio C HamanoJan 31, 2006
  29. Johannes SchindelinFeb 1, 2006
  30. FranckJan 31, 2006

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.