Re: [PATCH 4/7] docs: exclude documentation for commands that have been excluded

> On Mon, Apr 15, 2019 at 12:16:51AM -0400, Eric Sunshine wrote:
>
> > On Sun, Apr 14, 2019 at 11:10 PM Junio C Hamano <gitster@pobox.com> wrote:
> > > Eric Sunshine <sunshine@sunshineco.com> writes:
> > > >> +Documentation/GIT-EXCLUDED-PROGRAMS: Makefile config.mak.uname
> > > >> +       $(QUIET_GEN)echo "EXCLUDED_PROGRAMS := $(EXCLUDED_PROGRAMS)" >$@
> > > >
> > > > Should this rule also have a dependency upon "config.mak.autogen"?
> > >
> > > That is probably a good point.
> > >
> > > > Perhaps like this:
> > > >
> > > > Documentation/GIT-EXCLUDED-PROGRAMS: Makefile $(wildcard config.mak*)
> > >
> > > I'd rather not let changes to "config.mak-", which I keep in my
> > > working tree (untracked and disabled copy of config.mak, that can be
> > > readily activated by renaming), be part of dependency rules.
> > >
> > > If we know 'autogen' is the only dependency that optionally can
> > > exist, then depending explicitly on $(wildcard config.mak.autogen)
> > > would be a better alternative.
> >
> > When composing that email, I originally wrote $(wildcard
> > config.mak.autogen) as the suggestion but changed it to the looser
> > $(wildcard config.mak*) when I realized that the developer's own
> > config.mak probably ought to be a dependency, as well. Taking your
> > objection into consideration, we could mention both explicitly:
> >
> >     Documentation/GIT-EXCLUDED-PROGRAMS: Makefile \
> >         $(wildcard config.mak) $(wildcard config.mak.autogen)
>
> What about command-line options that influence the outcome? It sounds
> like this is the same problem we have in lots of other places (like say,
> compiler flags being updated), that we solve by generating the proposed
> file output unconditionally and comparing it to what's on disk.  E.g.,
> see the way GIT-CFLAGS or GIT-BUILD-OPTIONS is generated.