[Libreoffice] git submodule

[Miklos Vajna]

On Sun, Feb 06, 2011 at 05:44:03AM -0600, Norbert Thiebaud <nthiebaud at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20110207/80ab91b1/attachment.pgp>