Re: [HACKERS] Deriving release notes from git commit messages
Robert Haas
> On Fri, 24 Jun 2011 13:42:04 -0400
> Robert Haas <rober...@gmail.com> wrote:
>
>> As for annotating the commit messages, I think something like:
>>
>> Reporter: Sam Jones
>> Author: Beverly Smith
>> Author: Jim Davids
>> Reviewer: Fred Block
>> Reviewer: Pauline Andrews
>
> Can I just toss in one little note from the sidelines? �Various other
> projects (Linux kernel at the top of the list) have adopted tags like
> Reported-by and Reviewed-by for metadata like this. �(Authorship lives in
> git itself, with additional authors sometimes ambiguously indicated with
> additional Signed-off-by lines). �There are tools out there which make use
> of those tags now. �It would seem that, in the absence of a reason to make
> up your own tags, it might make sense to be consistent with other projects?
I'm not averse to inventing our own tags that fit our particular
needs, but I don't think it would be a bad idea to maximize the
intersection of what we do with what other people do.
I think the biggest difference is probably that we (or at least I)
don't really like the idea of Signed-off-by, and certainly not as a
way of ambiguously indicating additional authors. Many patches are
collaborative efforts, and the metadata should make that clear.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Jonathan Corbet
Robert Haas <rober...@gmail.com> wrote:
> As for annotating the commit messages, I think something like:
>
> Reporter: Sam Jones
> Author: Beverly Smith
> Author: Jim Davids
> Reviewer: Fred Block
> Reviewer: Pauline Andrews
Can I just toss in one little note from the sidelines? Various other
projects (Linux kernel at the top of the list) have adopted tags like
Reported-by and Reviewed-by for metadata like this. (Authorship lives in
git itself, with additional authors sometimes ambiguously indicated with
additional Signed-off-by lines). There are tools out there which make use
of those tags now. It would seem that, in the absence of a reason to make
up your own tags, it might make sense to be consistent with other projects?
Thanks,
jon
Andres Freund
> I wouldn't have a problem with establishing a convention that we
> write credits in commit messages in a more standardized way, ie put
> something like "Author: Joe Blow <j...@blow.nom>" in the body of the
> commit message. However, the points that were raised about commit
> messages being effectively uncorrectable after-the-fact seem to me
> to put a big crimp in the idea of using that as the primary source
> of credit information. We'd still need something like the web app
> Robert described in <BANLkTimOxDA08qM4...@mail.gmail.com>
> to allow correction of the info.
There are git notes which you can attach to a commit after the fact... I like
the fact that they would keep the information in the repository (where they
seem to belong).
Andres
Robert Haas
> On Saturday, July 02, 2011 06:10:43 AM Tom Lane wrote:
>> I wouldn't have a problem with establishing a convention that we
>> write credits in commit messages in a more standardized way, ie put
>> something like "Author: Joe Blow <j...@blow.nom>" in the body of the
>> commit message. However, the points that were raised about commit
>> messages being effectively uncorrectable after-the-fact seem to me
>> to put a big crimp in the idea of using that as the primary source
>> of credit information. We'd still need something like the web app
>> Robert described in <BANLkTimOxDA08qM4...@mail.gmail.com>
>> to allow correction of the info.
> There are git notes which you can attach to a commit after the fact... I like
> the fact that they would keep the information in the repository (where they
> seem to belong).
Yeah, but I think it's still basically append-only, which is kind of a
nuisance, and it means they can only be updated by committers, which
is not particularly helpful from my point of view.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Martijn van Oosterhout
> > There are git notes which you can attach to a commit after the fact... I like
> > the fact that they would keep the information in the repository (where they
> > seem to belong).
>
> Yeah, but I think it's still basically append-only, which is kind of a
> nuisance, and it means they can only be updated by committers, which
> is not particularly helpful from my point of view.
The documentation says:
"This command allows you to add/remove notes to/from objects, without
changing the objects themselves."
So it doesn't appear append only. I think the idea is that every object
can have one note. How that works with versioning I have no idea.
Have a nice day,
--
Martijn van Oosterhout <kle...@svana.org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle
Tom Lane
> On Sat, Jul 02, 2011 at 03:45:03PM -0400, Robert Haas wrote:
>>> There are git notes which you can attach to a commit after the fact... I like
>>> the fact that they would keep the information in the repository (where they
>>> seem to belong).
>> Yeah, but I think it's still basically append-only, which is kind of a
>> nuisance, and it means they can only be updated by committers, which
>> is not particularly helpful from my point of view.
> The documentation says:
> "This command allows you to add/remove notes to/from objects, without
> changing the objects themselves."
> So it doesn't appear append only. I think the idea is that every object
> can have one note. How that works with versioning I have no idea.
A look at the git-notes man page says that you can only have one note
per commit, but you can edit that note, and git does track the revision
history of each note.
I think that we should adopt "git notes" as a better solution than
making dummy whitespace changes when we want to put a commit-message
correction into the commit history (you listening, Bruce?).
But as Robert says, this still leaves the committers as the gatekeepers
for the information, so it's not clear to me that this is a good way to
solve the problems that Greg was talking about originally. I'd rather
have a solution that offloads the work from the committers.
regards, tom lane
Andres Freund
> A look at the git-notes man page says that you can only have one note
> per commit, but you can edit that note, and git does track the revision
> history of each note.
>
> I think that we should adopt "git notes" as a better solution than
> making dummy whitespace changes when we want to put a commit-message
> correction into the commit history (you listening, Bruce?).
> But as Robert says, this still leaves the committers as the gatekeepers
> for the information, so it's not clear to me that this is a good way to
> solve the problems that Greg was talking about originally. I'd rather
> have a solution that offloads the work from the committers.
I don't think its that hard to write a hook which allows notes changes for a
different set of people than source changes.
Whether the people wanting to annotate commits are ok with using git I do not
know.
Andres
Magnus Hagander
> On Sunday, July 03, 2011 06:46:15 PM Tom Lane wrote:
>> A look at the git-notes man page says that you can only have one note
>> per commit, but you can edit that note, and git does track the revision
>> history of each note.
>>
>> I think that we should adopt "git notes" as a better solution than
>> making dummy whitespace changes when we want to put a commit-message
>> correction into the commit history (you listening, Bruce?).
That sounds like a reasonable use for git notes.
> There is git commit --allow-empty btw
>
>> But as Robert says, this still leaves the committers as the gatekeepers
>> for the information, so it's not clear to me that this is a good way to
>> solve the problems that Greg was talking about originally. �I'd rather
>> have a solution that offloads the work from the committers.
> I don't think its that hard to write a hook which allows notes changes for a
> different set of people than source changes.
> Whether the people wanting to annotate commits are ok with using git I do not
> know.
If you want a different group of people to maintain it, then why force
it into the same repository in the first place? Having to write hooks
to work around things with that seems to be solving the wrong problem,
imho.
--
�Magnus Hagander
�Me: http://www.hagander.net/
�Work: http://www.redpill-linpro.com/
Andres Freund
> On Sun, Jul 3, 2011 at 20:04, Andres Freund <and...@anarazel.de> wrote:
> > On Sunday, July 03, 2011 06:46:15 PM Tom Lane wrote:
> >> A look at the git-notes man page says that you can only have one note
> >> per commit, but you can edit that note, and git does track the revision
> >> history of each note.
> > for a different set of people than source changes.
> > Whether the people wanting to annotate commits are ok with using git I do
> > not know.
>
> If you want a different group of people to maintain it, then why force
> it into the same repository in the first place? Having to write hooks
> to work around things with that seems to be solving the wrong problem,
> imho.
patch. I can't forsee a really useful usage of that information without the
commit alongside...
Andres
Bruce Momjian
> Martijn van Oosterhout <kle...@svana.org> writes:
> > On Sat, Jul 02, 2011 at 03:45:03PM -0400, Robert Haas wrote:
> >>> There are git notes which you can attach to a commit after the fact... I like
> >>> the fact that they would keep the information in the repository (where they
> >>> seem to belong).
>
> >> Yeah, but I think it's still basically append-only, which is kind of a
> >> nuisance, and it means they can only be updated by committers, which
> >> is not particularly helpful from my point of view.
>
> > The documentation says:
> > "This command allows you to add/remove notes to/from objects, without
> > changing the objects themselves."
>
> > So it doesn't appear append only. I think the idea is that every object
> > can have one note. How that works with versioning I have no idea.
>
> A look at the git-notes man page says that you can only have one note
> per commit, but you can edit that note, and git does track the revision
> history of each note.
>
> I think that we should adopt "git notes" as a better solution than
> making dummy whitespace changes when we want to put a commit-message
> correction into the commit history (you listening, Bruce?).
Yes, I heard. I don't think I have done that since we moved to git.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +