On Sat, Jul 24, 2010, skillzero@xxxxxxxxx napisał: > On Fri, Jul 23, 2010 at 3:50 PM, Avery Pennarun <apenwarr@xxxxxxxxx> wrote: > > > Honest question: do you care about the wasted disk space and download > > time for these extra files? Or just the fact that git gets slow when > > you have them? > > I have the similar situation to the original poster (huge trees) and > for me it's all three: disk space, download time, and performance. My > tree has a few relatively small (< 20 MB) shared directories of common > code, a few large (2-6 GB) directories of code for OS's, and then > several medium size (< 500 MB) directories for application code. The > application developers only care about the app+shared directories (and > are very annoyed by the massive space and performance impact of the OS > directories). The firmware-only developers only care about OS+shared > and are mildly annoyed by the medium space and performance impact of > the app directories. I work on all of the pieces, but even I would > prefer to have things separated so when I work on the apps, git > status/etc doesn't take a big hit for close to a million files in the > OS directories (particularly when doing git status on Windows). Even > when using the -uno option to git status, it's still pretty slow (over > a minute). > > git-submodule might be technically possible in this situation, but > having to commit and push each submodule and then commit and push the > super module makes it slightly worse than just dealing with the > space/download/performance issues of one huge repository. But this is just a matter for improving UI for dealing with submodules, isn't it. For example having "git commit --recursive" would help with 'having to commit each submodule', though how you would write commit messages then: perhaps supermodule commit message could be by default composed out of submodules commits (if any). "git push --recursive" (or some support for push in "git remote") would help with 'having to push each submodule'. Isn't it? -- Jakub Narebski 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