Re: do we want to gitignore regression-test-failure files?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: do we want to gitignore regression-test-failure files?
Date: 2010-09-26 20:28:20
Message-ID: 16655.1285532900@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-09-26 20:38:23 Re: [COMMITTERS] pgsql: Still more tweaking of git_changelog.
Previous Message Marios Vodas 2010-09-26 20:20:42 forming tuple as an attribute inside another tuple in c function