Re: clone breaks replace

[Phillip Susi <psusi@cfl.rr.com>]

On 1/11/2011 3:00 PM, Johannes Sixt wrote:
> On Dienstag, 11. Januar 2011, Jeff King wrote:
>> I think you missed the first part of this discussion. Phillip is
>> proposing that it should, and I am arguing against it.
> 
> You're right, sorry for the noise. Now I understand this three-word-subject.

What it really comes down to is that you can use replace locally to
modify your history and it works great.  As soon as someone clones from
you though, they don't get the replace and so they end up with a
different history than you see.

I suggested that git-upload-pack should respect replace records by
default, so that people cloning your repository will get the same
replaced history instead of the original.

It seems that the recommended use of replace is to locally append
history back on, after it has been removed upstream with git
filter-branch.  Using filter-branch is bad, so it makes more sense to me
to do the remove with git replace, and then if you want to add it back,
you just have to disable the replace ( and maybe fetch additional objects ).

The one problem that has come up is that when you fetch and tell the
server you have a commit after the replace, it assumes that you also
have the commits prior to the replace and may delta against objects you
do not have.  Fixing that would require informing the server of any
replacements you have, and it being able to use that information to
avoid deltas against objects hidden by the replace.

Does that sound like a pretty good summary to everyone?