Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html