On Thu, Jun 12, 2008 at 09:14:21AM +0200, Johan Herland wrote: > > The grafts file isn't part of the object stream and refs, and clones (and > > fetches) very much just copy the object database. > > AFAICS, there's already a perfectly fine way to distribute grafted history: > 1. Add a grafts file > 2. Run git-filter-branch > 3. Remove grafts file > 4. Distribute repo > 5. Profit! > > Since git-filter-branch turns grafted parentage into _real_ parentage, > there's no point in ever having a grafts file at all (except transiently > for telling git-filter-branch what to do). But then you have rewritten all of the later commits, so you can no longer talk to other people about them. The kernel repo is split into "historical" and active repos. You can graft the historical repo and get more far-reaching answers to things like "git log" and "git blame". But if you run filter-branch, you can't share development on that repo via push / pull to people who _don't_ use the graft, since they don't share your history (and they probably don't want to, because of the extra resources required to pull in the historical chunk). That being said, I don't know how common such a setup is. And you did mention a "follow-grafts" config option for such people. -Peff -- 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
