On Fri, 26 Jan 2007, Junio C Hamano wrote: > > 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. One option might be: - add a global flag (like the current "save_commit_buffer") that commands can set to specify whether they want to honor grafts or not. The "please_follow_grafts" flag defaults to 1. - "git send-pack" would explicitly set it to zero, and thus we'd always send a non-grafted result. - "git prune" would *also* explicitly set it to zero, but would also manually look at the grafts file, and mark anything that is set in the grafts file as being reachable (the same way it does for index entries etc). It might also be an option to then do: - "git repack" should probably also set it to zero - I think we might be better off packing any grafted data separately. The alternative, of course, is to try to transfer the grafts file for clones and fetches, but that is likely to be a *bad* idea. It's even a potential security issue: grafts can literally be used to short-circuit some of the inherent safety in git, in that an attacker can make a graft that makes history *look* fine, but hide part of it (you can't "really" hide history, but you can make normal git operations like "git log" basically ignore it by judicious use of grafts). Linus - 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