From: Emily Shaffer <nasamuffin@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Vinayak Dev <vinayakdev.sci@gmail.com>, git@vger.kernel.org
Subject: Re: Documentation/MyFirstObjectWalk: add #include "trace.h" to use trace_printf()
Date: Thu, 29 Jun 2023 16:06:17 -0700 [thread overview]
Message-ID: <CAJoAoZnaU7WsCpnZY0Pvjg4_GJMZADF0FNC9fNZK56ShX2JO+g@mail.gmail.com> (raw)
In-Reply-To: <xmqq1qhu9ifp.fsf@gitster.g>
On Thu, Jun 29, 2023 at 12:28 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Emily Shaffer <nasamuffin@google.com> 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.
>
next prev parent reply other threads:[~2023-06-29 23:06 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-29 16:05 Documentation/MyFirstObjectWalk: add #include "trace.h" to use trace_printf() Vinayak Dev
2023-06-29 16:33 ` Emily Shaffer
2023-06-29 16:35 ` Emily Shaffer
2023-06-29 18:45 ` Vinayak Dev
2023-06-29 23:09 ` Emily Shaffer
2023-06-30 5:48 ` Vinayak Dev
2023-06-30 15:39 ` Vinayak Dev
2023-06-29 19:28 ` Junio C Hamano
2023-06-29 23:06 ` Emily Shaffer [this message]
2023-06-30 2:21 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJoAoZnaU7WsCpnZY0Pvjg4_GJMZADF0FNC9fNZK56ShX2JO+g@mail.gmail.com \
--to=nasamuffin@google.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=vinayakdev.sci@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).