Обсуждение: do we want to gitignore regression-test-failure files?

Seems like it's probably a good idea, but I wanted to double-check
that no one has a different thought.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Robert Haas <robertmhaas@gmail.com> writes:
> Seems like it's probably a good idea, but I wanted to double-check
> that no one has a different thought.

-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'm a bit surprised that you think this is a good idea while not
favoring having, say, *.rej in the ignore configuration.

I'd be inclined to put this in the category of things that people can
ignore in their personal configurations if they think it's a good idea.

If we were going to do this, we'd need it in a lot more places than
just src/test/regress/ --- I think it'd really need to be a global
ignore.
        regards, tom lane

On Sun, Sep 26, 2010 at 3:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Seems like it's probably a good idea, but I wanted to double-check
>> that no one has a different thought.
>
> -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?

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

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

On Sun, Sep 26, 2010 at 4:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

What is this, some kind of game of chicken?  Surely we're trying to
settle on a sensible rule here, not get into a mud-wrestling match.  I
can live with the rule you've articulated but I think it's more
complicated than necessary, and I certainly don't want to see it
further complicated.  Let's get it written down in a README file
someplace and not be moving the goalposts henceforth.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

Tom Lane <tgl@sss.pgh.pa.us> writes:
> 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?

Couldn't resist to note that $EDITOR might make it easy to divert the
backup files elsewhere (out-of-tree). For example:
 (setq backup-directory-alist '((".*" . "~/.emacs.d/backups/")))

Regards,
-- 
dim