Re: grafts+repack+prune = history at danger

[Junio C Hamano <junkio@cox.net>]

Johannes Sixt <J.Sixt@eudaptics.com> writes:

> Oh, the original repo *does* loose the object after step 3, but you
> would not notice it until you remove the grafts file.

That is Ok -- you did want to lose that object B because you
told git you want to pretend A's parent is not B in _your_ local
repository.

>> grafts are local matter for archaeologist's convenience to glue
>> two independent histories together, and not much more.
>
> Agreed. Then grafts must be disregarded by (almost) all plumbing, most
> notably fsck-objects, prune, pack-objects,...

You are not agreeing.

Graft is a local matter, but that does not mean it should
introduce inconsistencies.  It is a way to _locally_ change the
world view, and to give the consistent world view locally, not
only the commands you listed (fsck, prune, pack-objects) but
also log, rev-list and friends all should take grafts into
account, which is why losing B is the right thing to do if you
repack or prune.  In your altered world, B is not part of any
remaining history.

The problem you noticed is a limitation of fetch/clone.
Exposing the locally modified world view to the other end so
that a cloned repository has the exactly the same view by
copying the grafts file would be trivial [*1*].

However, it is rather tricky if you try to extend it to fetching
into an existing repository.  Which may have its own grafts and
define an altered world view in its own way.  And that altered
world view may conflict (e.g. it may already say the parent of A
is not B but not X as in the repository you are cloning from but
some other commit Y).

That's why traditionally we just punt the whole issue by saying
don't exchange objects between repositories that have grafts
without thinking (primarily because we haven't thought things
through -- we are lazy bastards).

One thing you could do is to take the local-ness of grafts more
literally and enforce it more strictly by dropping grafts while
fetch-pack and receive-pack exchange common objects and spawn
pack-objects to come up with objects needed to be sent.  But
because we currently punt, we do not even do that.

If we were to spend the effort to do that temporary dropping of
grafts (which I would expect to be quite ugly code), I suspect
we are better off thinking things through to define the desired
semantics, what should happen when objects are exchanged between
two repositories that have their world views altered with their
grafts.  The end result would most likely update the info/grafts
in your repository when you fetch from a repository with grafts,
and probably update info/grafts at the remote when you push from
a repository with grafts.

[*1*] It does require fetch-pack protocol update, though, so it
is some work.  It is still trivial in the sense that it is clear
what is needed to realize exactly the same the world view -- the
copy should have the exact copy of info/grafts file.