Re: clone breaks replace

[Jonathan Nieder <jrnieder@gmail.com>]

Phillip Susi wrote:

> Take the kernel history as an example, only imagine that Linus did not
> originally make that first commit leaving out the prior history, but
> wants to go back and fix it now.  He can do it with a replace, but then
> if he runs filter-branch as you suggest to make the change 'real', then
> everyone tracking his tree will fail the next time they try to pull.
> You could get the same result without replace, so why bother?
>
> If the replace was fetched by default, the people already tracking would
> get it the next time they pull and would not have a problem.

Interesting.  I hadn't thought about this detail before.

> Those cloning the repository for the first
> time would get it, and avoid fetching all of the old history since they
> would be using the replace record in place of the original commit.

No, it doesn't work that way.  Imagine for a moment that each commit
object actually contains all of its ancestors.  That isn't precisely
right but in a way it is close.

To change the ancestry of a commit, you really do need to change its
name.  If you disagree, feel free to try it and I'd be glad to help
where I can with the coding if the design is sane.  Deal?

Maybe it would be nice if git replace worked that way, but that would
be fundamentally a _different_ feature.