> > Don't worry; I didn't feel offended. The Travis stuff running on > > the branches at http://github.com/git/git would surely catch issues > > on MacOSX and/or around git-p4 (neither of which I test myself when > > merging to 'pu') before they hit 'next', and that is already helping > > us greatly. > > I agree that it helps to catch those Mac and P4 issues early. > > However, it is possible that bogus errors are reported that might not have > been introduced by the changes of the PR, and I find it relatively hard to > figure out the specifics. Take for example > > https://travis-ci.org/git/git/jobs/124767554 > > It appears that t9824 fails with my interactive rebase work on MacOSX, > both Clang and GCC versions. I currently have no access to a Mac for > developing (so I am denied my favorite debugging technique: sh t... -i -v > -x), and I seem to be unable to find any useful log of what went wrong > *specifically*. > > Any ideas how to find out? You could patch .travis.yml on top of your changes to run only t9824 (so travis-ci returns feedback faster) and to run it with additional options '-i -x', push it to github, and await developments. I'm not saying it's not cumbersome, because it is, and the p4 cleanup timeout loop with '-x' is particularly uninteresting... but it works, though in this case '-x' doesn't output anything useful. You could also check how independent branches or even master are faring, and if they fail at the same tests, like in this case they do, then it's not your work that causes the breakage. It seems you experience the same breakage that is explained and fixed in this thread: http://thread.gmane.org/gmane.comp.version-control.git/291917 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html