On Tue, Dec 01, 2009 at 01:58:05PM -0500, Greg A. Woods wrote: > > > > I just disagreed that "git archive" was a reasonable alternative to > > > leaving the working directory alone during the entire time of the build. > > > > Using "git archive" allows you avoid running long time procedure such as > > full clean build and testing in the working tree. Also, it is guaranteed > > that you test exactly what you put in Git and some other garbage in your > > working tree does not affect the result. > > Sure, but let's be very clear here: "git archive" is likely even more > impossible for some large projects to use than "git clone" would be to > use to create build directories. AFAIK, "git archive" is cheaper than git clone. I do not say it is fast for huge project, but if you want to run a process such as clean build and test that takes a long time anyway, it does not add much to the total time. > > Disk bandwidth is almost always more expensive than disk space. Disk bandwidth is certainly more expensive than disk space, and the whole point was to avoid a lot of disk bandwidth by using hot cache. If you have two working tree then it is likely that only one will be in the hot cache, that is why you can switch faster (and to recompile a few files) than going to another working tree. It has never been about disk space, it is about disk cache and keeping it hot. > > Multiple working directories are really the only sane solution > sometimes. Sure, sometimes... I do not know details to say what will be better in your case, but I just wanted to say that you should weight that against switching, because switching in Git is very fast. Much faster than with any other VCS... Another thing to consider is that if you put a really huge project in one Git repo than Git may not be as fast as you may want, because Git tracks the whole project as the whole. So, you may want to split your project in a few relatively independent modules (See git submodule). Dmitry -- 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