Thread: .gitignore patch for coverage builds
Building for coverage and running the reports littered my tree with files which should probably be in .gitignore for just such a contingency. Patch attached. -Kevin
Attachment
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > Patch attached. The coverage directory belongs under "Local excludes in root directory". Version 2. -Kevin
Attachment
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Building for coverage and running the reports littered my tree with
> files which should probably be in .gitignore for just such a
> contingency. Patch attached.
Ick. That's an awful lot of stuff to have global ignores for.
Perhaps we should recommend people do coverage tests in separate
build trees, instead.
regards, tom lane
On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes: >> Building for coverage and running the reports littered my tree with >> files which should probably be in .gitignore for just such a >> contingency. Patch attached. > > Ick. That's an awful lot of stuff to have global ignores for. The "coverage" directory ignore seems a little icky, but the rest seems unlikely to pick up anything incidental. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Ick. �That's an awful lot of stuff to have global ignores for.
> The "coverage" directory ignore seems a little icky, but the rest
> seems unlikely to pick up anything incidental.
Tying /coverage to the root as in his V2 makes that better, but I'm
still unexcited about the thesis that we should auto-ignore the results
of any random tool somebody wants to run in their source tree.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'm still unexcited about the thesis that we should auto-ignore > the results of any random tool somebody wants to run in their > source tree. Hos about just the tools supported by our documentation, configure file and make file? -Kevin
Excerpts from Tom Lane's message of mié ene 26 19:20:52 -0300 2011: > Robert Haas <robertmhaas@gmail.com> writes: > > On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Ick. That's an awful lot of stuff to have global ignores for. > > > The "coverage" directory ignore seems a little icky, but the rest > > seems unlikely to pick up anything incidental. > > Tying /coverage to the root as in his V2 makes that better, Hmm, I don't think that works, because you can run "make coverage" in any subdir and it will create a "coverage" subdir there. > but I'm > still unexcited about the thesis that we should auto-ignore the results > of any random tool somebody wants to run in their source tree. Well, in this case it's not any random tool, because it's integrated into our makefiles. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
On Wed, Jan 26, 2011 at 2:41 PM, Alvaro Herrera <alvherre@commandprompt.com> wrote: > Excerpts from Tom Lane's message of mié ene 26 19:20:52 -0300 2011: >> Robert Haas <robertmhaas@gmail.com> writes: >> > On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> >> Ick. That's an awful lot of stuff to have global ignores for. >> >> > The "coverage" directory ignore seems a little icky, but the rest >> > seems unlikely to pick up anything incidental. >> >> Tying /coverage to the root as in his V2 makes that better, > > Hmm, I don't think that works, because you can run "make coverage" in > any subdir and it will create a "coverage" subdir there. I like being told that I have a coverage directory outstanding when I run "git status". The hundreds of other files, not so much. >> but I'm >> still unexcited about the thesis that we should auto-ignore the results >> of any random tool somebody wants to run in their source tree. > > Well, in this case it's not any random tool, because it's integrated > into our makefiles. I agree. Should this be added to commit-fest 2011-Next? Also, should "make clean-coverage" be changed to remove all of those files from the entire tree and not just root? Cheers, Jeff
On Mon, Feb 14, 2011 at 7:38 PM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Wed, Jan 26, 2011 at 2:41 PM, Alvaro Herrera > <alvherre@commandprompt.com> wrote: >> Excerpts from Tom Lane's message of mié ene 26 19:20:52 -0300 2011: >>> Robert Haas <robertmhaas@gmail.com> writes: >>> > On Wed, Jan 26, 2011 at 4:44 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> >> Ick. That's an awful lot of stuff to have global ignores for. >>> >>> > The "coverage" directory ignore seems a little icky, but the rest >>> > seems unlikely to pick up anything incidental. >>> >>> Tying /coverage to the root as in his V2 makes that better, >> >> Hmm, I don't think that works, because you can run "make coverage" in >> any subdir and it will create a "coverage" subdir there. > > I like being told that I have a coverage directory outstanding when I > run "git status". > > The hundreds of other files, not so much. > > >>> but I'm >>> still unexcited about the thesis that we should auto-ignore the results >>> of any random tool somebody wants to run in their source tree. >> >> Well, in this case it's not any random tool, because it's integrated >> into our makefiles. > > I agree. Should this be added to commit-fest 2011-Next? I think there's little reason not to go ahead and commit this now. It's a trivial patch, Tom is the only one objecting, and there are at least four votes on the other side. The only question in my mind is whether we ought to try to ignore the coverage directories, or just the other glob patterns. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On ons, 2011-01-26 at 15:38 -0600, Kevin Grittner wrote: > "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: > > > Patch attached. > > The coverage directory belongs under "Local excludes in root > directory". Version 2. I have committed a simplified version of this, except the coverage/ directory, which some people had issues with. I think it's OK to "manually" ignore that.