Re: do we want to gitignore regression-test-failure files? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: do we want to gitignore regression-test-failure files?
Date
Msg-id 16655.1285532900@sss.pgh.pa.us
Whole thread Raw
In response to Re: do we want to gitignore regression-test-failure files?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: do we want to gitignore regression-test-failure files?
Re: do we want to gitignore regression-test-failure files?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> -1. �If the lack of an ignore causes a problem for you, it indicates
>> that you're trying to commit code that fails the regression tests.
>> Is it really a good idea to let that happen without any manual cleanup?

> I think it just means that the regression tests have failed at some
> point since the last time you cleaned out your tree.  Those files
> don't get removed on a successful make check, do they?

Yes, they do.  If they are present, then your last attempted check
failed.  Maybe you fixed the problem afterwards, but you didn't prove it
by retesting.

> The reason I assumed we'd want to ignore these is because they're
> automatically generated files - unlike *.rej files, which are never
> going to end up in your tree as a result of make anything.  It doesn't
> actually matter that much to me in practice, except that I fear
> creating a complex and indecipherable rule about what to ignore vs.
> not.

I don't find it indecipherable.  We're ignoring stuff that can be
expected to be present after a normal build and successful "make
check" or "make installcheck".  As soon as we ignore more than that,
I'm going to insist on ignoring *~ ... do you want to open that can
of worms?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Marios Vodas
Date:
Subject: forming tuple as an attribute inside another tuple in c function
Next
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.