Linus Torvalds wrote:Ok, but couldn't this be considered a variation of a lightweight checkout? The only reason I'm worried about this is the case where the superproject contains *thousands* of subprojects. Eg, a superproject for all repo.or.cz projects. Say in a day 200 projects get updated with a few commits - do you have to do 200 pulls or just one? But maybe that problem can be solved in another way, or maybe it won't really hurt so much in practice and still be faster/more efficient than rsync mirroring. This is especially the case in concert with gittorrent, which will need modifications to support sharing multiple repositories (not that that's a huge issue, given there's no implementation yet). Well fsck can be fixed easily enough to not descend, like lightweight checkouts. What I really want to avoid is the situation where you can't checkout, even though you didn't indicate a shallow/lightweight clone. What else might this decision impact? Obviously with a smaller base you have fewer delta targets, though that's probably not a real issue. Sam. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Zhang, Yanmin | AIM7 40% regression with 2.6.26-rc1 |
| Con Kolivas | [PATCH][RSDL-mm 0/7] RSDL cpu scheduler for 2.6.21-rc3-mm2 |
| Nick Piggin | [patch 4/6] mm: merge populate and nopage into fault (fixes nonlinear) |
| Andrew Morton | -mm merge plans for 2.6.23 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Natalie Protasevich | [BUG] New Kernel Bugs |
