On 19 Jan 2015, at 18:23, [email protected] wrote:
> BUILD FAILURE
>
> Build URL: https://build.barrywardell.net/job/EinsteinToolkit/409/
> Project: EinsteinToolkit
> Date of build: Mon, 19 Jan 2015 17:13:41 +0000
> Build duration: 9 min 29 sec
>
> Changes
>
> Revision: 68cdcc5ecc34e0fac714e13a5a53016651a64903
> Author: Einstein Toolkit Git Server
> Log:
> Updated submodules:
>
> * arrangements/CactusBase 11f4180...9b1bab2 (1):
> > CactusBase: Support CCTK_INT16
>
> * arrangements/CactusNumerical 93a286d...49912fb (1):
> > CactusNumerical: Support CCTK_INT16
>
> * arrangements/CactusPUGH 0ac5c78...cb3c70f (1):
> > PUGH: Support CCTK_INT16
>
> * arrangements/CactusTest 8c3b35b...48004a2 (1):
> > TestAllTypes: Test CCTK_INT16
>
> * repos/carpet 7ddf438...2efdefc (2):
> > CarpetLib: Disable new bboxset class if the compiler does not support
> C++11
> > Merge branch 'eschnett/int16'
Hi,
This test failure was caused by the git super-repository update system not
successfully updating the flesh in its working copy. I believe this was caused
by somebody pushing a commit which rewrote the flesh history. From the
repository history I can see, I think this was the push by Erik at 15-Jan-2015
19:12 which added commit
104612e - Cactus: Output schedule routine when outputting warnings
(2014-12-31) <Erik Schnetter>
with parent
c7fd13a - Merged in redirect_root (pull request #2) (2014-12-30) <Frank
Löffler>
The master branch then evolved from this commit. However, there were already
more commits on master, including
065b00c - Merged in simple_make_for_single_config (pull request #6)
(2015-01-12) <Frank Löffler>
f47e1d0 - (origin/simple_make_for_single_config) Don't require
configuration name when only one is present anyway. (2014-12-25) <Frank
Loeffler>
9c7a72a - Merged in Makefile_invalid_configuration_names (pull request
#5) (2015-01-12) <Frank Löffler>
which were then lost. These commits were then added onto the end of master (I
think again by Erik?), so that the code was correct, but the history was
different.
I'm basing this on the history I can see in the update server's copy of the
repository, and the commit email notifications which give the timeline of
pushes.
This could have been caused by Erik rebasing his master branch off a feature
branch, instead of the other way around, and then overriding the warning when
pushing to bitbucket by adding the --force option to "git push". Erik, is it
possible that this is what happened?
The super-repo update system should have detected the failure to update and
sent me an email, but there is a bug there which means it ignored the error. I
have corrected the repository problem on the update server.
I believe the current master branch contains all the code that it should, and
that it will now update correctly, unless another forced push is performed.
Possible actions:
– We could disable forced pushes in bitbucket for the master branch to
stop this happening again (this should presumably be done for all the
repositories, so it should be done by a script).
– The super-repo update system should be fixed so that errors like this
are detected and reported
--
Ian Hinder
http://members.aei.mpg.de/ianhin
_______________________________________________
Users mailing list
[email protected]
http://lists.einsteintoolkit.org/mailman/listinfo/users
