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

Re: clone breaks replace

From
PSPhillip Susi <psusi@cfl.rr.com>
Date
Jan 8, 2011, 00:43 UTC
Message-ID
<4D27B33C.2020907@cfl.rr.com>
In-Reply-To
<20110107220942.GB10343@sigill.intra.peff.net>
On 01/07/2011 05:09 PM, Jeff King wrote:
Show 14 quoted lines
> I think there are two separate issues here:
>
>    1. Should transport protocols respect replacements (i.e., if you
>       truncate history with a replacement object and I fetch from you,
>       should you get the full history or the truncated one)?
>
>    2. Should clone fetch refs from refs/replace (either by default, or
>       with an option)?
>
> Based on previous discussions, I think the answer to the first is no.
> The resulting repo violates a fundamental assumption of git. Yes,
> because of the replacement object, many things will still work. But many
> parts of git intentionally do not respect replacement, and they will be
> broken.

What parts do not respect replacement? More importantly, what parts will be broken? The man page seems to indicate that about the only thing that does not by default is reachability testing, which to me means fsck and prune. It seems to be the purpose of replace to /prevent/ breakage and be respected by default, unless doing so would cause harm, which is why fsck and prune do not.

Show 5 quoted lines
> Instead, I think of replacements as a specific view into history, not a
> fundamental history-changing operation itself. Which means you can never
> save bandwidth or space by truncating history with replacements. You can
> only give somebody the full history, and share with them your view. If
> you want to truncate, you must rewrite history[1].

Right, but if you only care about that view, then there is no need to waste bandwidth fetching the original one. It goes without saying that people pulling from the repository mainly care about the view upstream chooses to publish. Upstream can choose to rewrite, which will cause breakage and is a sort of sneaky way to hide the original history, or they can use replace, which avoids the breakage and gives the client the choice of which view to use.

Previous: Christian CouderNext: Jeff King
Message 19 of 34 in “clone breaks replace”
  1. Phillip SusiJan 6, 2011
  2. Jonathan NiederJan 6, 2011
  3. Junio C HamanoJan 6, 2011
  4. Phillip SusiJan 7, 2011
  5. Jonathan NiederJan 7, 2011
  6. Stephen BashJan 7, 2011
  7. Jonathan NiederJan 7, 2011
  8. Phillip SusiJan 7, 2011
  9. Jonathan NiederJan 7, 2011
  10. Phillip SusiJan 7, 2011
  11. Jeff KingJan 7, 2011
  12. Junio C HamanoJan 7, 2011
  13. Jeff KingJan 11, 2011
  14. Junio C HamanoJan 11, 2011
  15. Jeff KingJan 11, 2011
  16. Jonathan NiederJan 11, 2011
  17. Jeff KingJan 11, 2011
  18. Christian CouderJan 11, 2011
  19. Phillip SusiJan 8, 2011
  20. Jeff KingJan 11, 2011
  21. Jonathan NiederJan 11, 2011
  22. Phillip SusiJan 11, 2011
  23. Jonathan NiederJan 11, 2011
  24. Phillip SusiJan 11, 2011
  25. Phillip SusiJan 11, 2011
  26. Jeff KingJan 11, 2011
  27. Johannes SixtJan 11, 2011
  28. Jeff KingJan 11, 2011
  29. Johannes SixtJan 11, 2011
  30. Phillip SusiJan 11, 2011
  31. Jonathan NiederJan 11, 2011
  32. Phillip SusiJan 12, 2011
  33. small downloads and immutable history (Re: clone breaks replace)Jonathan Nieder, Jan 14, 2011
  34. Phillip SusiJan 15, 2011

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.