Re: [PATCH] disable grafts during fetch/push/bundle

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@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).