Re: clone breaks replace
- From
- Phillip Susi <psusi@cfl.rr.com>
- Date
- Jan 11, 2011, 15:24 UTC
- Message-ID
- <4D2C7611.6060204@cfl.rr.com>
- In-Reply-To
- <20110111054735.GC10094@sigill.intra.peff.net>
On 1/11/2011 12:47 AM, Jeff King wrote:
> Once you have fetched with that view, how locked into that view are you? > Certainly you can never push to or be the fetch remote for another > repository that does not want to respect that view, because you simply > don't have the objects to complete the history for them.
If you want to fetch the original history, then it is as simple as git --no-replace-objects fetch. Unless of course, the upstream repository actually removed the original history ( or you are pulling from someone else who only pulled the truncated history ), possibly transplanting it to a historical repository that they should refer you to in the message of the replace commit. Then you just fetch from there instead, and viola! You have the complete original history.
Show 6 quoted lines
> I guess you can get the parent pointer from the real, "non-replaced" > object and ask for it. But you can't ask for a specific commit, so for > every such truncation, the parent needs to publish an extra ref (but > _not_ make it one of the ones fetched by default, or it would nullify > your original shallow fetch), and we need to contact them and find that > ref.
Yes, either a new branch or separate historical repository could be published to pull the original history from, or git would need to pass the --no-replace-objects flag to git-upload-pack on the server, causing it to ignore the replace and send the original history.