On Fri, Jul 18, 2008 at 04:09:40PM +0100, Nigel Magnay wrote: > Hmm. Locally modifying my .gitmodules still feels bad because I don't > like either of those tradeoffs (but I don't have any sensible > suggestion yet). > > As a bit of background (as to why I'd dislike (a) and (b)), we had a > team switch to git, and one of the really nice things is the ability > to share stuff around and branch freely - but the flipside of that is > that we tend to push to a central repo more rarely, so the advantages > of an continuous integration server become less. What we did is to > tell a centralised CI server the URLs of all the team's git > repositories, and it would periodically pull from them, speculatively > compile anything new, and run the big suite of tests - finishing up by > emailling them a heads-up that a particular state in their repo is > 'bad'. > > This was really popular as it was demonstrably better than anything we > could do with svn, and best of all, it's pretty much transparent - as > a user you don't have to do anything at all. > > I could do it now by hacking about with files; it'd just be nice to > keep it transparent and make it a directly supported feature. In that case you would need the "URL mappings", perhaps as a per-remote attribute. That is, you could configure: "When I am doing git pull fred, do git submodule update but apply remote.fred.subrewrite sed script on each URL before fetching the submodule." Still, that feels quite hackish to me, and I'm not convinced that your workflow cannot be adjusted so that users merge only the next-to-last commit of a branch instead of the last one. -- Petr "Pasky" Baudis As in certain cults it is possible to kill a process if you know its true name. -- Ken Thompson and Dennis M. Ritchie -- 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
