Re: Questions about the new refs/replace mechanism

[Jakub Narebski <jnareb@gmail.com>]

Johannes Sixt <j.sixt@viscovery.net> writes:

> Sergio schrieb:

> > 3) If I remember correctly, there was a reason why grafts were not
> > considered suitable for transferring across repos. Can someone
> > remind me about it? How does the replace mechanism address this
> > issue?
> 
> The problem with grafts was that, for example, git-pack-objects obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.

To be more detailed, the problem is that if git-pack-objects, git-fsck
and git-gc obeys grafts, it can create broken repository by removing
grafted away objects.  If git-pack-objects, git-fsck and git-gc
doesn't obey grafts, it can created broken repository (well, broken if
we include grafts) by removing grafted in objects.

> 
> OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> never obey replace entries in the history. But they do keep track of them
> (and the history that they reference) because they are referenced from the
> refs/replace namespace.

In the case of refs/replace git-pack-objects, git-fcsk and git-gc
doesn't "obey" refs/replace... but replaced objects are protected by
pruning by being referenced from refs/replace ref.

One of problems with grafts file was to come up with rule what do do
if both repository you fetch from and the repository you fetch into
have both grafts; in the case of refs/replace the usual rules about
(conflicting) refs apply.

It is also easy to select whether to follow refs/replace or not: you
fetch them into your refs/replace or not; you would have to add extra
option to git-fetch to select whether to fetch and follow grafts in
remote you fetch from.

-- 
Jakub Narebski
Poland
ShadeHawk on #git