Обсуждение: pgsql: Remove outdated comments from the regression test files.
Remove outdated comments from the regression test files. Since 2004, int2 and int4 operators do detect overflow; this was fixed by commit 4171bb869f234281a13bb862d3b1e577bf336242. Extracted from a larger patch by Andres Freund. Branch ------ master Details ------- http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=8d70ed84ba577abf9e985518024fb92e2081dac9 Modified Files -------------- src/test/regress/expected/int2.out | 2 -- src/test/regress/expected/int4.out | 2 -- src/test/regress/sql/int2.sql | 2 -- src/test/regress/sql/int4.sql | 2 -- 4 files changed, 0 insertions(+), 8 deletions(-)
Robert Haas wrote: > Remove outdated comments from the regression test files. > > Since 2004, int2 and int4 operators do detect overflow; this was fixed by > commit 4171bb869f234281a13bb862d3b1e577bf336242. > > Extracted from a larger patch by Andres Freund. I noticed with this commit that we are referencing pre-git-conversion git branches, basically adding a dependency on git to our commit messages. I don't see a problem with this, but did we ever reference CVS details in CVS commits? I don't remember any. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Bruce Momjian <bruce@momjian.us> writes:
> Robert Haas wrote:
>> Remove outdated comments from the regression test files.
>>
>> Since 2004, int2 and int4 operators do detect overflow; this was fixed by
>> commit 4171bb869f234281a13bb862d3b1e577bf336242.
>>
>> Extracted from a larger patch by Andres Freund.
> I noticed with this commit that we are referencing pre-git-conversion
> git branches, basically adding a dependency on git to our commit
> messages. I don't see a problem with this, but did we ever reference
> CVS details in CVS commits? I don't remember any.
I've usually preferred to use a date, eg, "my patch of 2009-10-07",
when referring to previous patches in commit messages. I think people
have occasionally mentioned CVS revision IDs, but the folly of that
should now be obvious. I agree that reference to a git hash is way
way way too fragile and git-centric.
regards, tom lane
Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > Robert Haas wrote: > >> Remove outdated comments from the regression test files. > >> > >> Since 2004, int2 and int4 operators do detect overflow; this was fixed by > >> commit 4171bb869f234281a13bb862d3b1e577bf336242. > >> > >> Extracted from a larger patch by Andres Freund. > > > I noticed with this commit that we are referencing pre-git-conversion > > git branches, basically adding a dependency on git to our commit > > messages. I don't see a problem with this, but did we ever reference > > CVS details in CVS commits? I don't remember any. > > I've usually preferred to use a date, eg, "my patch of 2009-10-07", > when referring to previous patches in commit messages. I think people > have occasionally mentioned CVS revision IDs, but the folly of that > should now be obvious. I agree that reference to a git hash is way > way way too fragile and git-centric. Who's going to be the first to say that being git-centric can't ever be a bad thing? ;-) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
On Nov 27, 2010, at 2:49 PM, Bruce Momjian <bruce@momjian.us> wrote: > Who's going to be the first to say that being git-centric can't ever be > a bad thing? ;-) At least for me, referring to it that way makes finding the original patch an order of magnitude faster (git show hash). YMMV. ...Robert
Robert Haas <robertmhaas@gmail.com> writes:
> On Nov 27, 2010, at 2:49 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> Who's going to be the first to say that being git-centric can't ever be
>> a bad thing? ;-)
> At least for me, referring to it that way makes finding the original patch an order of magnitude faster (git show
hash). YMMV.
[ shrug... ] You need to take the long view here. We're not working on
the assumption that git is the last SCM this project will ever use.
Even granting that it is, I don't think git hashes are adequately stable;
loading the code into a different repository would likely result in new
hashes. And AFAIK there is no mechanism that would fix hash references
embedded in commit log messages (or the code).
regards, tom lane