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 11, 2011, 15:37 UTC
Message-ID
<4D2C7948.6080304@cfl.rr.com>
In-Reply-To
<20110111065244.GB8631@burratino>
On 1/11/2011 1:52 AM, Jonathan Nieder wrote:
> I have two worries:
> 
>  - first, how easily can the replacement be undone? (as you mention
>    below)

git replace -d id, or git --no-replace-objects. It also might be nice to add a new switch to git replace to disable a replace without deleting it, so that it can later be enabled again.

>  - second, what happens if the two ends of transport have different
>    replacements?

Then you have a conflict, just like if the two ends have different tags with the same name.

Show 8 quoted lines
> That second worry is the more major in my opinion.  Shallow clones are
> a different story --- they do not fundamentally change the history and
> they have special support in git protocol.  It is possible to punt on
> both by saying that (1) replacements _cannot_ be undone --- a second
> replacement is needed --- and (2) the receiving end of a connection is
> not allowed to have any replacements for objects in common that the
> sending end does not have, but then does that buy you anything
> significant over a filter-branch?

One of the major advantages of replacements is that they can easily be undone, so defeating that would be silly. Just like with conflicting tags, if the receiving end has conflicting replacements, they will be kept instead of the remote version and a warning issued. If you want the remote version, delete your local one and fetch again.

What it buys you over filter-branch is:
1)  Those tracking your repo don't have breakage when they next fetch
because the chain of commits they were tracking has been destroyed and
replaced by a completely different one.
2)  It is obvious when a replace has been done, and the original is
still available.  This is good for auditing and traceability.  Paper
trails are good.
3)  Inserting a replace record takes a lot less cpu and IO than
filter-branch rewriting the entire chain.
Previous: Jonathan NiederNext: Jonathan Nieder
Message 22 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.