On Jan 20, 2015, at 8:01 , Ian Hinder <[email protected]> wrote: > 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?
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 > [email protected] > http://lists.einsteintoolkit.org/mailman/listinfo/users -- Erik Schnetter <[email protected]> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://lists.einsteintoolkit.org/mailman/listinfo/users
