Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, Jul 14, 2011 at 11:37 AM, Jeff King <peff@xxxxxxxx> wrote: > > > > There's also one other issue with generation numbers. How do you handle > > grafts and object-replacement refs? If you graft history, your embedded > > generation numbers will all be junk, and you can't trust them. > > So I don't think this is a real problem in practice. > > Grafts are already unreliable. You cannot sanely merge over a graft, > and it has nothing to do with generation numbers. > > I'm actually sorry that we ever did grafting. It's fundamentally > broken, and can actually destroy your repository (by hiding real > parents and then causing the commits to get garbage collected). So I > don't think grafting should be used as an argument for or against > anything - it's a hack that breaks some fundamental git database > constraints. What about object-replacement refs (i.e. "git replace" and refs/replace/)? This is modern replacement for grafts mechanism, which is safe against garbage collecting, and contrary to grafts it is transferable (as a ref). With replacement objects (e.g. to repair some fragment of history to make it bisectable - I think that was original idea behind introducing git-replace, or instead of grafts to join with historical repository - IIRC the reason why grafts mechanism was created) you can also have invalid generation numbers if they are stored in commit headers. With generation cache we can simply invaliate it if grafts or replacements change... P.S. grafts are quite useful when doing history surgery. Create grafts, check history, use git-filter-branch to make new DAG permanent, remove grafts. P.P.S. What about "grafts lite", i.e. shallow clone? With generation cache we can invalidate it when depth changes... -- Jakub Narębski Poland -- 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