Re: clone breaks replace
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Jan 7, 2011, 21:49 UTC
- Message-ID
- <20110107214907.GA9194@burratino>
- In-Reply-To
- <4D278930.7010100@cfl.rr.com>
Phillip Susi wrote:
Show 9 quoted lines
> 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.