On Thu, Jun 29, 2023 at 12:28 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Emily Shaffer <nasamuffin@xxxxxxxxxx> writes: > > > Yeah, it's almost certainly stale in MyFirstObjectWalk - there was > > very recently a patch to clean up some headers which probably were > > implicitly including trace.h when I wrote this walkthrough. > > We are lucky that we have folks like Vinayak who tried out the > examples and then bothered to spend time reporting the failure > discovered. What does it take, however, for us to have a bit more > automated way to prevent such a breakage that comes from API > changes? Is it feasible, for example, to add a test that extracts > code snippets from the MyFirstObjectWalk document and try to build > the result? Alternatively, we can ship such a set of sample source > files somewhere in our tree (e.g. contrib/examples?) and have such > a test try to build using the current set of source files, but then > we need a mechansim to ensure that the sample source files will not > go out of sync with the document. Yeah, I remember we talked about this when MyFirstContribution and MyFirstObjectWalk went in, but never made much headway. I do very much like the idea of keeping the reference source in contrib/ as a set of patches, maybe along with a script to apply them (or a readme with the right `git am` invocation), and then checking that they still build. Checking that against the contents of the document is trickier, though, like you mentioned. Hm. I'm interested in figuring out how to do this, but not likely to have a lot of development time available to do it. Maybe I can take a day here or there to poke at it, but if someone else is interested and beats me to it, I will not be disappointed. :) > > Thoughts? > > Thanks. >
