On Sat, Jan 30, 2016 at 5:22 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: > >> > Personally I don't see value in having the commit message follow a >> > machine-parseable format; like if you say "Backpatch to" instead of >> > "Backpatch-through:" makes your commit message wrong. I think what was >> > being proposed is to have committers ensure that the commit messages >> > always carried the necessary info (which, as far as I know, they do.) >> >> Well, this gets at one of the problems here, which is that you can't >> fix a commit message once the commit has been pushed. > > Yes, I'm aware that this is a problem. I tried to raise the point that > we could use "git notes" to provide additional information after the > fact but was quickly made to shut up before it could be recorded in the > minutes.
Yeah, shut up, Alvaro! We don't want to hear about you and your fancy technological solutions! :-) > If we were to adopt git notes or a similar system(*), we could use those > as a mechanism to install the machine-parseable data for each commit, > which I think fixes all the problems you point out. I haven't experimented enough to know whether it would or not, but I think it would be interesting to find out whether it would or not. > (*) Another idea that comes to mind now that you mention this database > thingy of yours is to make a table or tables with commits and their > associated data, which could initially be populated from the commit > message and later updated. Yeah. It's a crazy thought, but it's almost like this databasey thing was designed precisely for the purpose of allowing people to structure their data in relational ways and then interact with it in convenient fashion. Personally, I think that if we had a database of commit metadata, we could use that to do all sorts of interesting reporting. I don't think any of that reporting is absolutely necessary for the survival of the project, but sometimes things that aren't absolutely necessary can still be awfully nice. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers