On Sat, Feb 21, 2015 at 6:51 AM, Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
