Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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 -- 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