Re: [COMMITTERS] pgsql: Remove outdated comments from the regression test files.

On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Nov 27, 2010, at 2:49 PM, Bruce Momjian <bruce(at)momjian(dot)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).

Well, if we ever did want to rewrite the entire development history
(why?) I suppose we could rewrite SHA hashes in the commit messages at
the same time. But I think one big advantage of git (or svn, or
probably any other post-CVS VCS) is that it has unique IDs for
commits. Referring to them as "the commit by so-and-so on
such-and-such a date" just on the off chance that we might someday
decide to replace those unique IDs with another set of unique IDs
doesn't make much sense to me. It makes things more difficult now in
the hope that, ten years from now when we switch systems again, it'll
be easier to use unstructured text to construct a search command to
root through the development history than it will be to map a git
commit id onto a commit id in the new system. That's possible, but
it's far from obvious. We are database professionals; we ought to
believe in the value of unique keys.

In fact, I'd go a bit further and say that moving in the direction of
MORE unstructured text is the last thing that our commit messages
need. Right now, I follow your practice of writing the author of a
patch separated from the last paragraph of the commit message by a
blank line, additionally noting the reviews and others who have
contributed (or who reported the problem). The syntax falls short of
machine-parseable, though. Other committers do different things,
listing the author at the end of the paragraph of commit text, or
preceding it with "Author:", or burying it somewhere in the middle, or
even writting "Commit so-and-so's patch to do something-or-other." It
is impossible to construct a meaningful history of code contributions
without grepping the logs for each person's name individually; that's
a lot less helpful than it could be, especially since there's no
comprehensive list of name to grep for. Perhaps it's too late to fix
up the history (though we could annotate it with git notes if someone
were willing to do the legwork), but we could certainly do better
going forward if we were so inclined. We ought to be looking for ways
to include MORE structured information, not less.

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