Hi Emily, On Wed, Apr 15, 2020 at 7:01 PM Emily Shaffer <emilyshaffer@xxxxxxxxxx> wrote: > > On Wed, Apr 15, 2020 at 6:28 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > > > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > > > Danh Doan <congdanhqx@xxxxxxxxx> writes: > > > > > >> Excerpt from build log: > > >> > > >>> fatal error C1083: Cannot open include file: 'config-list.h' > > >> > > >> It's from bugreport topic. > > >> I've seen this failure in the past (when testing with pu), > > >> then I saw it disappear. > > >> > > >> I thought it was fixed during my testing for v4. > > > > > > Is the issue something similar to 976aaedc (msvc: add a Makefile > > > target to pre-generate the Visual Studio solution, 2019-07-29)? > > > > > > If that is the case, perhaps something like this would help? I'll > > > tentatively queue it on top of es/bugreport and merge the result to > > > 'pu' to see what happens. > > > > The build just passed: https://github.com/git/git/runs/590781044 > > > > Emily, you may need to squash in something along the line of this > > change to the commit in your series that starts building and using > > the config-list.h file (was it the first one?). I've queued mine > > as a follow-up "oops, it was wrong" patch, but that would not be > > kosher from bisectability's point of view. > > Hm, ok. I'll send a reroll squashing this in verbatim tomorrow unless > I hear otherwise from Dscho? Looks like it's indeed the first one > (dd763e). > I'm curious to know how I can check this build method for myself for next time. Create a fork of github.com/git/git and open a pull request against it. (I believe you could also fork github.com/gitgitgadget/git and do a pull request against it, but I switched over to /git/git a while ago.) Immediately upon opening the pull request, a bunch of linux, mac, windows, and freebsd builds will be triggered with various runs of the testsuite. Has been very useful for catching issues for me before I sent them off to the list. You can also make use of Dscho's gitgitgadget magic at that point to take care of the git send-email step for you too by commenting '/submit' in the PR, though you don't have to do that. It's perfectly fine to just open a PR for the automated testing and then close the PR and do the rest yourself. But if you leave it open and have it submit the patch emails for you, it'll track their status. I kinda like being able to go to https://github.com/git/git/pulls/newren and have it track the state of where all my open pull requests are. (You might even be able to click through some of those to see example build results) Dscho has done some great work with his gitgitgadget work and azure builds. SZEDER Gábor also has a few builds triggered via Travis that check a few more things off the same PRs (static anlysis and whatnot). I've been very happily using them all by just opening PRs, and have appreciated the heads up of potential issues I would've otherwise caused on various platforms otherwise. Hope that helps, Elijah
