Re: [COMMITTERS] pgsql: Remove outdated comments from the regression test files.
От | Robert Haas |
---|---|
Тема | Re: [COMMITTERS] pgsql: Remove outdated comments from the regression test files. |
Дата | |
Msg-id | AANLkTimG=OdnkpetBnfkLLAG3B_gJTDQrpd1AwnR+-yY@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Remove outdated comments from the regression test files. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Remove outdated comments from
the regression test files.
(Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
|
Список | pgsql-hackers |
On Sat, Nov 27, 2010 at 3:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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). 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
В списке pgsql-hackers по дате отправления: