Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree)
От | Michael Paquier |
---|---|
Тема | Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) |
Дата | |
Msg-id | CAB7nPqRp1CTNAkqurh8PxCMw0A1ztLNAXfiy8rtTfZ07fT0whA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Enforce creation of destination folders for source
files in pg_regress (Was: pg_regress writes into source tree)
Re: Enforce creation of destination folders for source files in pg_regress (Was: pg_regress writes into source tree) |
Список | pgsql-hackers |
On Sat, Feb 21, 2015 at 6:51 AM, Peter Eisentraut <peter_e@gmx.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
В списке pgsql-hackers по дате отправления: