On 7/2/08, Stephen R. van den Berg <srb@xxxxxxx> wrote: > Dmitry Potapov wrote: > >On Wed, Jul 2, 2008 at 10:10 PM, Stephen R. van den Berg <srb@xxxxxxx> wrote: > >> In that case, I will stick to extending git fsck to check grafts more > >> rigorously and fix git clone to *refrain* from looking at grafts. > > >Linus suggested that "git-fsck and repacking should just consider > >it[grafts] to be an _additional_ source of parenthood rather than > >a _replacement_ source." > > >http://article.gmane.org/gmane.comp.version-control.git/84686 > > Yes, I know that's what he suggested, the way it should be implemented > IMO though is by checking once without and once with regard to grafts. > And still it should be such that git clone disregards grafts completely. I could see an argument that the only modes you really need are a) use grafts as replacements, and b) use grafts as additions. There is perhaps no need for c) ignore grafts. For example, say I wanted to give someone a copy of my repo that includes grafts (ignoring the fact that this is probably bad to do in general). He could git-clone it and then install a copy of my grafts file, as long as git-clone does (a) or (b) but not (c). On the other hand, if he just wants a copy of the "real" (graft-free) repo, then git-clone needs to do (b) or (c) but not (a). git-fsck needs (b), and most normal git operations want (a) (since that was the original purpose of grafts). Based on that, (c) is redundant, unless you're really concerned about not sending redundant objects to people who clone your repo that has grafts installed. But I think you probably shouldn't have people cloning your grafted repository anyway unless you know what you're doing, and if you know what you're doing, you probably want (b). If you see what I mean. Have fun, Avery -- 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
