On Jan 20, 2015, at 8:01 , Ian Hinder ian.hinder@aei.mpg.de wrote:
On 19 Jan 2015, at 18:23, ian.hinder@aei.mpg.de 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?
Yes, this is possible. I'm also working in another project where the developers very much insist on a clean history, so I'm rebasing and force-pushing there all the time. (They believe that a clean history helps git-bisect -- I very much disagree; rebasing creates commits that no human every saw and that were never compiled, so it doesn't avoid intermediate build failures, but that's beside the point here.) I did get myself into a bind with pulling, merging, and resolving conflicts, and I force-pushed to the int16 branch to resolve this. (Bad habit, easy to adopt.)
I may have force-pushed to the wrong branch. Since my GUI doesn't support force-pushing, I have to do it from the shell. Probably easy to be on the wrong branch there. Sorry. Yes, please disable it, including for Carpet.
-erik
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 Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
-- Erik Schnetter schnetter@gmail.com http://www.perimeterinstitute.ca/personal/eschnetter/
My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from https://sks-keyservers.net.