On 28.11.2010 06:59, Robert Haas wrote:
On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane<t...@sss.pgh.pa.us> wrote:
Robert Haas<robertmh...@gmail.com> writes:
On Nov 27, 2010, at 2:49 PM, Bruce Momjian<br...@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).
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.
Let's do both: "This fixes the bug introduced by the foobar patch from
Sep 12th (git commitid a2c23897bc).
I like to see the date of the referred patch in the commit message, to
get an immediate idea of whether it was a 5-year old change or something
from the previous day. But the commitid is also nice so you can
immediately copy-paste that without reading through the old commit logs.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
