Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes: > Sure, if I connect my linux repo with a graft to the historical BK tree, > then toss the ref that pointed to the historical tree, then git prune: > - then currently it won't prune the historical tree > - but under my proposal it would. Silly me. Why did I remove that ref? If your version of git worked the way you describe, the only reason you removed that ref would be to make sure that your altered view would be destroyed (you won't be able to do "git log" across that graft boundary anymore). Indeed that would be a silly thing to do. Thankfully, the real git does not behave that way. That is why fsck/prune _must_ honor grafts. That makes the locally altered view consistent. To the altered world view, what are stored in the object database do not change, but your view of how they are connected does. And if your altered view thinks commit v2.6.12-rc2 has one of the commits in the bkcvs history as its parent, you do not want to lose that history merely because you lost a ref to it -- as long as the commit tagged as v2.6.12-rc2 is reachable, its (imaginary) parent should be as well. If you want to switch out of an altered universe, you may need to do more than just remove grafts (objects that were hidden by grafts were immaterial in the altered universe, but now you may need to get them back, as in your fixed-up imported repository example, and objects that existed only because grafts pulled them in are now made unreachable and become prunable), but that goes without saying. If you want to make it easier to switch back and forth between altered reality and the real world, fsck/prune/repack may need to be taught to consider both real and grafted parents to be connected, so that you do not have to lose objects that will become necessary when you come out of the altered world, but I am not sure if it is worth it. If you prune while in the real world the "both real and grafted" safety would obviously not kick in when you run prune, so when you reinstall the grafts, some of the necessary objects would be already gone. - 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