Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)

On Sat, Feb 21, 2015 at 6:51 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 2/20/15 1:56 AM, Michael Paquier wrote:
>>> We'd still need the .gitignore files somewhere. Do you want to move
>>> them one directory up?
>>
>> I am not sure I am getting what you are pointing to... For extensions
>> that already have non-empty sql/ and expected/, they should have their
>> own ignore entries as sql/.gitignore and expected/.gitignore. The
>> point of the patch is to simplify the code tree of extensions that
>> need to keep empty sql/ and expected/, for example to be able to run
>> regression tests after a fresh repository clone for example.
>
> The affected modules have sql/.gitignore and/or expected/.gitignore
> files, so the case that the directory doesn't exist and needs to be
> created doesn't actually happen.

What about extensions that do not have sql/ and extended/ in their
code tree? I don't have an example of such extensions in my mind but I
cannot assume either that they do not exist. See for example something
that happended a couple of months back, dummy_seclabel has been
trapped by that with df761e3, fixed afterwards with 3325624 (the
structure has been changed again since, but that's the error showed up
because of those missing sql/ and expected/).

> You could argue that these .gitignore files don't actually belong there,
> but your patch doesn't change or move those files, and even modules that
> have non-empty sql/ or expected/ directories have .gitignore files
> there, so it is considered the appropriate location.

This is up to the maintainer of each extension to manage their code
tree. However I can imagine that some people would be grateful if we
allow them to not need sql/ and expected/ containing only one single
.gitignore file ignoring everything with "*", making the code tree of
their extensions cleaner.
--
Michael