On Sun, Feb 06, 2011 at 05:44:03AM -0600, Norbert Thiebaud <nthiebaud@gmail.com> wrote:
humm... what build.git ? :-) on master I do not even clone build.git anymore...
Then bootstrap.git, you get it. :)
Con: it seriously increase the barrier of entry. git already scare some people... git + submodule at that scale will be much worse Con: it would be using submodule in a way it was certainly not intended to be used. That means that doc and support for that will be scarse and chance of screwing things up rise big time, with very few 'expert' - if any - to sort things out. Con: how well is it going to mesh with the fact that some git repo are 'optional' (l10n) ? Con: that will probably mess with the hg import script. we would need to make sure that import is still feasible - without breaking the current history Note that the main drawback of our current approach is indeed the bisection problem. It would be certainly be convinient to be able to bisect on the entire set of repos... but how much pain/risk do we want to take to improve that aspect of things ?
I already thought about this when the first gitdm script was hacked by Cedric to handle all the repos as a single one (and I managed to came up with a solution there), but that does not help bisecting. If it was not clear from my mail, git-submodule is (in its current form) a no-go for us IMHO. Of course svn externals-like behaviour would not really improve the situation, either. What I can imagine as a working solution is that we already have a tinbuild which can detect if a certain set of git heads (of the repos) is buildable or not. Now tinbuild could publish those "working sets" to a githeads.git repo and a 'g bisect' could work from that data. Of course that will not find the exact commit like tinbuild does not do, either - but at least point out a few possible ones. (I mean tinbuild would push the contents of git-heads.txt to a githeads.git, then 'g bisect' would call 'git bisect' in githeads.git and after the working directory is updated there, it would check out the commits in the repos based on git-heads.txt so that it's possible to do the actual testing. That's not so hard to implement for bisect start/good/bad/reset.) Does this sound reasonable? I'm happy to first implement the tinbuild part if others agree that the idea is sane. Of course you can call the repo bisect.git or whatever, that's a minor detail.
Attachment:
pgpjsTIOv6mbI.pgp
Description: PGP signature