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
Attachments:
gitignore-regression-failures.patchapplication/octet-stream; name=gitignore-regression-failures.patchDownload
diff --git a/src/test/regress/.gitignore b/src/test/regress/.gitignore
index 7573add..72da567 100644
--- a/src/test/regress/.gitignore
+++ b/src/test/regress/.gitignore
@@ -5,3 +5,7 @@
/tmp_check/
/results/
/log/
+
+# Error output
+/regression.diffs
+/regression.out
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