Johannes Sixt <J.Sixt@xxxxxxxxxxxxx> writes: > - the grafts file is not part of the objects database This is a very conscious design decision from an ancient times. It used to be fashionable to share object store across different repositories (you literally symlinked .git/objects), and grafts are local in the sense that they are per-repository, and that is the reason it lives in .git/info. There is not much reason either way and if I were doing this from scratch I would probably place it in .git/objects/info next to alternates. > - it is manipulated manually instead of by tools the check for errors Yes, but that is only because nobody saw need for such a tool so far. In reality, grafts have been pretty much "install and forget" thing. You graft 2.6.12-rc2 on top of the bkcvs tip once, and then do not think about it after doing so. When somebody sees a need, you know what will happen ;-). > - it is not transferred across clones/pulls/pushes (it's even possible > to create an inconsistent clone) Yes, as I already said that is where we punted and declared that the grafts are local matter. Even though your resulting clone is inconsistent, I do not even have to say "tough". You can just tell what the necessary graft file should look like to the repository owner at the other end, and the life will be peachy again. I even outlined the issues you (or somebody else who may be interested) would need to look into to make it more global. Do you need anything more? > The way out that I see is to make grafts much, much less important. Breaking what already works does not sound like a way out. For local-only, "install and forget" use, what the current setup does is consistent and works reasonably well. I would not say it is perfect, but I do not know of any outstanding bugs (and what you mentioned in these message are certainly not). - 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