From mboxrd@z Thu Jan  1 00:00:00 1970
From: jamie.couture at gmail.com (Jamie Couture)
Date: Wed, 30 Jul 2014 21:05:38 -0400
Subject: [PATCH] ui-tree.c: check source filter if set globally
In-Reply-To: <20140730211417.GK26927@serenity.lan>
References: <87a97t89to.fsf@columbia.edu>
 <1406746401-24187-1-git-send-email-jamie.couture@gmail.com>
 <20140730192321.GJ26927@serenity.lan>
 <20140730204717.GA7022@neptune>
 <20140730211417.GK26927@serenity.lan>
Message-ID: <20140731010538.GA9902@neptune>

On Wed, Jul 30, 2014 at 10:14:17PM +0100, John Keeping wrote:
> > Well, 'everything except source-filter' isn't really the case.
> 
> It is the case that all repo-specific settings except source-filter
> would be ignored if they come after the repository is loaded.
> 

Okay.

> > 
> > Maybe we do if users are having issues?  
> 
> Currently we support something like this:
> 
> 	scan-path=/path/to/world-a
> 	source-filter=/path/to/source-filter.sh
> 	scan-path=/path/to/world-b
> 
> Where the source filter isn't applied to "world-a".  I don't know if
> anyone makes use of this, but the current scheme does give quite a lot
> of flexibility.
> 

You got me.

This is a situation I have not considered to be a use-case others
may actually *want*.  I am not aware of anyone who does this in
practise, I know I do not do anything like that, but in
consideration of being most flexible we would lose that ability.

> > > Perhaps we would be better off making the documentation clearer rather
> > > than trying to fix some particular cases?
> > > 
> > 
> > I'm okay with this change, as long as it avoids problems for the
> > user. I don't think it introdces any sort of unwanted or unexpected
> > behaviour.  However, it should try to be more complete with the
> > remaining filter options.
> > 
> > I'm fine with this being turfed, but we do get a lot of questions
> > about scan-path problems.
> 
> I tend to think that shows that the documentation is lacking rather than
> the implementation, but I dunno.  Maybe I just don't want to deal with
> making sure that all repo variables fall back to the global one if it's
> set after scan-path or repo.url.

Indeed.  A solution, even to try and defer processing of
scan-path/scan-tree after we do parse_configfile() is awkward and
would defeat the use-case you mention above.

I'm not sure if the following adds much more value to the docs,
because it assumes people are going to configure cgitrc in a
specific way.

Maybe it would be better to include a _troubleshooting_ section to
README?  There we could repeat and assert that any global setting
defined after scan-path will not be defined.

-- 8< --
--- a/cgitrc.5.txt
+++ b/cgitrc.5.txt
@@ -378,6 +378,10 @@ scan-path::
        before the scan-path directive will be applied to each repository.
        Default value: none. See also: cache-scanrc-ttl, project-list,
        "MACRO EXPANSION".
++
+[NOTE]
+    It is general practise to define scan-path at the end of a cgitrc
+    file to ensure the global settings are used.

 section::
        The name of the current repository section - all repositories defined
-- 8< --