[Libreoffice] git submodule

[Norbert Thiebaud]

On Mon, Feb 7, 2011 at 11:10 AM, Miklos Vajna <vmiklos at frugalware.org> wrote:
> On Mon, Feb 07, 2011 at 09:38:14AM -0600, Norbert Thiebaud <nthiebaud at gmail.com> wrote:
>> How about having a after-push git-hook in the master branch in our
>> git.fdi/git/libreoffice/* git repos that generate the list of
>> HEAD-sha1
>> that was you should be able to almost-completely bisect.
>> sure in some cases the fact that 2 commit in two git are
>> interdependent would throw off the bisection. but that is not that
>> common.
>
> You mean when g commit && g push creates / pushes multiple commits?
>
> For example when you rename a function in a repo and fix the build in 3
> other ones.
>
> It would be really nice not to try to test the 3 ones where the build
> will obviously fail (and the tinbuild approach provides this).

The problem of the tinderbox approach is the coarse granularity (it is
not uncommon to have 1/2 a dozen or more of independent commit between
2 build, the reliability (tinderbox sometime are down and this is not
necessarily detected quickly).
furthermore if you only record 'good' tinderbox run, you may have a
few days of commit in one interval. if you don't then you are in
the same case than the scenario above (it doesn't build because of
interdependent commit);

One thing that we could do is that the pus-hook could do a commit
amend if the committer is the same that the very last one.
presumably linked commit on multiple repo are pushed 'together'
so if a push on repos A is immediately followed by a push on repo B
then the hook would do a git commit --amend instead of creating a new
version. that ways you usually fold all theses change into one
'list-head'
Of course you could have a race between two committer... but that is
_really_ rare.

Norbert

>OTOH of
> course that's possible - provided that those hooks still push the state
> to a githeads.git?
>
>> Another problem would be merge of feature branches, which would be
>> counted as just one bisect step for the whole branch.... (but that is
>> true even with the tinderbuild based solution)
>
> Sure - I don't have an idea either how to not count a merge as a single
> step with split repos.
>