> You don't want to track. The point is to remember, when you go back in > time, which revision is known to work. More importantly, when you tag, you > know exactly what you released.
what's the downside of having a repository composed of thousands of "update subrepo foo" commits? we're past a million svn commits now, that's a lot of committing - but now that I think about it I'm having trouble coming up wth an actual problem with that. apart from the potential cpu and network load for the update bot, which could be tiny for all I know. > When developing, however, just detach the submodule. Go into it, checkout > master or 4.3 or whatever and work on it. Sure, a "git status" in the > supermodule will produce "modified" for each directory where you've been > working, but why are you in the supermodule in the first place? hmm. what happens if $build-script does a "git pull" on hte supermodule after I do that? -- This message brought to you by eevil bananas and the number 3. www.chani3.com _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
