Sven Verdoolaege, Sun, Jul 15, 2007 13:51:48 +0200: > On Sun, Jul 15, 2007 at 12:47:12PM +0200, Alex Riesen wrote: > > Count me out. Junio convinced me instead and having tried the > > subprojects I find it really convenient: I can choose when and what > > should be updated and I can see what _can_ be updated, iff I decide > > to. Subprojects defined in such a loosely way are more flexible then > > having git-pull fetch subprojects by default. > > I agree that fetching should probably be left as a separate operation, > but if you have all the data, then I find it very inconvenient that > every time you switch to a different commit you have to update > all the subprojects separately too. I found I do _not_ need to do it every time I switch to a different commit. > Did you change your mind about this part too? Yep. I have less to transfer (and in fact, the subproject I mentioned is kind of heavy and has a lot of binary stuff in it). > > Sometimes I even want be > > _sure_ the subprojects are completely untouched (I have some critical > > parts in them). > > The update in the superproject would fail if the subproject is dirty > (just as with files.) Haven't noticed this yet. Merge ignores subprojects. What do you mean? - 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
