Jeff King <p...@peff.net> writes: > When we are creating a pack to send to a remote, we should > make sure that we are not respecting grafts or replace refs. > Otherwise, we may end up sending a broken pack to the other > side that does not contain all objects (either omitting them > entirely, or using objects that the other side does not have > as delta bases). > > We already make an attempt to do the right thing in several > places by turning off read_replace_refs. However, we missed > at least one case (during bundle creation), and we do > nothing anywhere to handle grafts.
"Doing nothing for grafts" has been pretty much a deliberate omission. Because we have no way to transfer how histories are grafted together, people cloning from a repository that grafts away a commit that records a mistakenly committed sekrit will end up with a disjoint history, instead of exposing the sekrit to them, and are expected to join the history by recreating grafts (perhaps a README of such a project instructs them to do so). That was deemed far better than exposing the hidden history, I think. And "replace tries to do the right thing" was an attempt to rectify that misfeature of grafts in that we now do have a way to transfer how the history is grafted together, so that project README does not have to instruct the fetcher of doing anything special. It _might_ be a misfeature, however, for the object connectivity layer to expose a part of the history replaced away to the party that fetches from such a repository. Ideally, the "right thing" ought to be to include history that would be omitted if we did not have the replacement (i.e. adding parents the underlying commit does not record), while not following the history that replacement wants to hide (i.e. excluding the commits replacement commits overlay). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
