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
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Linus Torvalds | Linux 2.6.27-rc5 |
| David Miller | Re: [PATCH] net: Fix the prototype of call_netdevice_notifiers |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
