Thread: Template for commit messages
There has been a request in the FOSDEM developers meeting that committers use a more consistent format for commit messages. This is the format I use: -- email subject limit ------------------------------------------- gitweb summary limit --------------------------ReportbyPatch byReviewed byBackpatch through The dashed lines are used to specify a target length for the summary line and are automatically removed before the commit message is posted. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On Thu, Jan 28, 2016 at 03:52:00AM -0500, Bruce Momjian wrote: > There has been a request in the FOSDEM developers meeting that > committers use a more consistent format for commit messages. This is > the format I use: Here is an updated version that includes a potential bug number: -- email subject limit ------------------------------------------- gitweb summary limit --------------------------ReportbyBug #Patch byReviewed byBackpatch through -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
Hi, On 01/28/2016 11:06 AM, Bruce Momjian wrote: > On Thu, Jan 28, 2016 at 03:52:00AM -0500, Bruce Momjian wrote: >> There has been a request in the FOSDEM developers meeting that >> committers use a more consistent format for commit messages. This is >> the format I use: > > Here is an updated version that includes a potential bug number: > > -- email subject limit ----------------------------------------- > -- gitweb summary limit -------------------------- > > > Report by > > Bug # > > Patch by > > Reviewed by > > Backpatch through Any reason why not to adapt the git message conventions from kernel? https://git.wiki.kernel.org/index.php/CommitMessageConventions I'd expect there are tools already working with that format, making the life easier for us. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 28, 2016 at 11:30:58AM +0100, Tomas Vondra wrote: > Any reason why not to adapt the git message conventions from kernel? > > https://git.wiki.kernel.org/index.php/CommitMessageConventions > > I'd expect there are tools already working with that format, making > the life easier for us. Good idea. :-) Updated template: -- email subject limit ------------------------------------------- gitweb summary limit --------------------------Reported-by:Bug:Patch-by:Reviewed-by:Backpatchthrough: I had to make up "Patch-by:" as it wasn't listed. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On Thu, Jan 28, 2016 at 11:49 AM, Bruce Momjian <bruce@momjian.us> wrote:
On Thu, Jan 28, 2016 at 11:30:58AM +0100, Tomas Vondra wrote:
> Any reason why not to adapt the git message conventions from kernel?
>
> https://git.wiki.kernel.org/index.php/CommitMessageConventions
>
> I'd expect there are tools already working with that format, making
> the life easier for us.
Good idea. :-) Updated template:
-- email subject limit -----------------------------------------
-- gitweb summary limit --------------------------
Reported-by:
Bug:
Patch-by:
Reviewed-by:
Backpatch through:
I had to make up "Patch-by:" as it wasn't listed.
The original format uses the author for that (author != committer in git), but that changes how we work a bit more. I'd be happy to just clal it "Author" rather than "Patch-by".
I also suggest a - in "Backpatch-through:" -- since all the others are intentionally mad ewithout a space, I assume that's for easier parsing.
They also had tested-by, it might be an idea to include that as well?
Bruce Momjian wrote: > There has been a request in the FOSDEM developers meeting that > committers use a more consistent format for commit messages. Let me point out that the reason this is being put forward is to make sure we have the reviewers listed for each patch, so that we can add a paragraph somewhere at the bottom of the release notes listing people that helped with the release. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Magnus Hagander wrote: > They also had tested-by, it might be an idea to include that as well? How about User-Interface-Bikeshedded-By: ? -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 28, 2016 at 11:53:44AM +0100, Magnus Hagander wrote: > The original format uses the author for that (author != committer in git), but > that changes how we work a bit more. I'd be happy to just clal it "Author" > rather than "Patch-by". > > I also suggest a - in "Backpatch-through:" -- since all the others are > intentionally mad ewithout a space, I assume that's for easier parsing. > > They also had tested-by, it might be an idea to include that as well? OK, updated based on those suggestions: -- email subject limit ------------------------------------------- gitweb summary limit --------------------------Reported-by:Bug:Author:Reviewed-by:Tested-by:Backpatch-through: -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
<p dir="ltr"><br /> Dne 28. 1. 2016 11:57 napsal uživatel "Alvaro Herrera" <<a href="mailto:alvherre@2ndquadrant.com">alvherre@2ndquadrant.com</a>>:<br/> ><br /> > Magnus Hagander wrote:<br />><br /> > > They also had tested-by, it might be an idea to include that as well?<br /> ><br /> > How about<br/> > User-Interface-Bikeshedded-By:<br /> > ?<p dir="ltr">+1<p dir="ltr">><br /> > --<br /> > ÁlvaroHerrera <a href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a><br /> > PostgreSQLDevelopment, 24x7 Support, Remote DBA, Training & Services<br />
On Thu, Jan 28, 2016 at 3:52 AM, Bruce Momjian <bruce@momjian.us> wrote: > There has been a request in the FOSDEM developers meeting that > committers use a more consistent format for commit messages. This is > the format I use: > > -- email subject limit ----------------------------------------- > -- gitweb summary limit -------------------------- > > > Report by > > Patch by > > Reviewed by > > Backpatch through > > The dashed lines are used to specify a target length for the summary > line and are automatically removed before the commit message is posted. One of the things I like about the current free-form approach is that you can indicate nuances, like: Person X reviewed an earlier version of this patch that was a lot different than this one. Person X reviewed this patch but didn't totally endorse it. Person X wrote the documentation for the patch, but none of the code. Person X wrote the vast bulk of this patch, even though there are some other authors. Should I just abandon the idea of trying to capture those details, or does this format contemplate a way to include them? (Also an important question: Has Tom agreed to use this new format? Because I think that anything the rest of agree on that he's not prepared to endorse is not going to have much value.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 01/28/2016 01:57 PM, Robert Haas wrote: ... > One of the things I like about the current free-form approach is that > you can indicate nuances, like: > > Person X reviewed an earlier version of this patch that was a lot > different than this one. > Person X reviewed this patch but didn't totally endorse it. > Person X wrote the documentation for the patch, but none of the code. > Person X wrote the vast bulk of this patch, even though there are some > other authors. > > Should I just abandon the idea of trying to capture those details, or > does this format contemplate a way to include them? Why can't we do both? That is, have a free-form text with the nuances, and then Reviewed-By listing the main reviewers? The first one is for humans, the other one for automated tools. > > (Also an important question: Has Tom agreed to use this new format? > Because I think that anything the rest of agree on that he's not > prepared to endorse is not going to have much value.) > I can't speak for Tom, but I'm sitting fairly close to him and I haven't heard any complains or even groaning. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: > On 01/28/2016 01:57 PM, Robert Haas wrote: >> One of the things I like about the current free-form approach is that >> you can indicate nuances, like: >> >> Person X reviewed an earlier version of this patch that was a lot >> different than this one. >> Person X reviewed this patch but didn't totally endorse it. >> Person X wrote the documentation for the patch, but none of the code. >> Person X wrote the vast bulk of this patch, even though there are some >> other authors. >> >> Should I just abandon the idea of trying to capture those details, or >> does this format contemplate a way to include them? > > Why can't we do both? That is, have a free-form text with the nuances, and > then Reviewed-By listing the main reviewers? The first one is for humans, > the other one for automated tools. I'm not objecting to or endorsing any specific proposal, just asking what we want to do about this. I think the trick if we do it that way will be to avoid having it seem like too much duplication, but there may be a way to manage that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote: >> How about >> User-Interface-Bikeshedded-By: >> ? > > +1 That's sort of implicitly pejorative. Maybe we could find another way to phrase that, like "Design-suggestions-by" or maybe a more general "Suggestions-by". -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote: > On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: > >> How about > >> User-Interface-Bikeshedded-By: > >> ? > > > > +1 > > That's sort of implicitly pejorative. Maybe we could find another > way to phrase that, like "Design-suggestions-by" or maybe a more > general "Suggestions-by". I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch, or to the discussion of labels for the commit messages. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On Thu, Jan 28, 2016 at 9:34 AM, Bruce Momjian <bruce@momjian.us> wrote: > On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote: >> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra >> <tomas.vondra@2ndquadrant.com> wrote: >> >> How about >> >> User-Interface-Bikeshedded-By: >> >> ? >> > >> > +1 >> >> That's sort of implicitly pejorative. Maybe we could find another >> way to phrase that, like "Design-suggestions-by" or maybe a more >> general "Suggestions-by". > > I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch, > or to the discussion of labels for the commit messages. I thought it was a proposed commit message label and that the original suggestion was tongue-in-cheek, but I might be misreading things. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra
> <tomas.vondra@2ndquadrant.com> wrote:
>> Why can't we do both? That is, have a free-form text with the nuances, and
>> then Reviewed-By listing the main reviewers? The first one is for humans,
>> the other one for automated tools.
> I'm not objecting to or endorsing any specific proposal, just asking
> what we want to do about this. I think the trick if we do it that way
> will be to avoid having it seem like too much duplication, but there
> may be a way to manage that.
FWIW, I'm a bit suspicious of the idea that we need to make the commit
messages automated-tool-friendly. What tools are there that would need
to extract this info, and would we trust them if they didn't understand
"nuances"?
I'm on board with Bruce's template as being a checklist of points to be
sure to cover when composing a commit message. I'm not sure we need
fixed-format rules.
regards, tom lane
Robert Haas wrote: > On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra > <tomas.vondra@2ndquadrant.com> wrote: > >> How about > >> User-Interface-Bikeshedded-By: > >> ? > > > > +1 > > That's sort of implicitly pejorative. Maybe we could find another > way to phrase that, like "Design-suggestions-by" or maybe a more > general "Suggestions-by". Apologies, I was kidding actually -- I don't think we should list people on patches just because they provided some input in the thread, but people that actually reviewed the patch. Otherwise we risk diluting the list in the release notes (or wherever it is that we end up crediting reviewers/contributors), which is also undesirable. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra >> <tomas.vondra@2ndquadrant.com> wrote: >>> Why can't we do both? That is, have a free-form text with the nuances, and >>> then Reviewed-By listing the main reviewers? The first one is for humans, >>> the other one for automated tools. > >> I'm not objecting to or endorsing any specific proposal, just asking >> what we want to do about this. I think the trick if we do it that way >> will be to avoid having it seem like too much duplication, but there >> may be a way to manage that. > > FWIW, I'm a bit suspicious of the idea that we need to make the commit > messages automated-tool-friendly. What tools are there that would need > to extract this info, and would we trust them if they didn't understand > "nuances"? > > I'm on board with Bruce's template as being a checklist of points to be > sure to cover when composing a commit message. I'm not sure we need > fixed-format rules. Well, I think what people are asking for is precisely a fixed format, and I do think there is value in that. It's nice to capture the nuance, but the nuance is going to get flattened out anyway when the release notes are created. If we all agree to use a fixed format, then a bunch of work there that probably has to be done manually can be automated. However, if we all agree to use a fixed format except for you, we might as well just forget the whole thing, because the percentage of commits that are done by you is quite high. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Thu, Jan 28, 2016 at 03:52:25PM +0100, Tom Lane wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra > > <tomas.vondra@2ndquadrant.com> wrote: > >> Why can't we do both? That is, have a free-form text with the nuances, and > >> then Reviewed-By listing the main reviewers? The first one is for humans, > >> the other one for automated tools. > > > I'm not objecting to or endorsing any specific proposal, just asking > > what we want to do about this. I think the trick if we do it that way > > will be to avoid having it seem like too much duplication, but there > > may be a way to manage that. > > FWIW, I'm a bit suspicious of the idea that we need to make the commit > messages automated-tool-friendly. What tools are there that would need > to extract this info, and would we trust them if they didn't understand > "nuances"? > > I'm on board with Bruce's template as being a checklist of points to be > sure to cover when composing a commit message. I'm not sure we need > fixed-format rules. I've been asking for them for years so I can spend my time on the PostgreSQL Weekly News more efficiently. Maybe it's more efficient for me to do this arranging than for each committer to do it. I'd like to imagine that committers are in a better position than I to summarize their work. Whatever we decide on here, I'd really appreciate it if every patch sent to the list came with a sentence describing what that version of it does, as scope drift frequently makes Subject: lines completely wrong. While I'm at it, I'd like to thank Andres Freund, Peter Geoghegan, and Robert Haas in particular for making a habit of writing detailed summaries and splitting patches into logical chunks. All errors in the PostgreSQL Weekly News are mine, but a little organization like theirs would go a very long way, and not just for me. Cheers, David. -- David Fetter <david@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fetter@gmail.com Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate
On 01/28/2016 06:57 AM, Robert Haas wrote: >> I'm on board with Bruce's template as being a checklist of points to be >> sure to cover when composing a commit message. I'm not sure we need >> fixed-format rules. > > Well, I think what people are asking for is precisely a fixed format, > and I do think there is value in that. It's nice to capture the > nuance, but the nuance is going to get flattened out anyway when the > release notes are created. If we all agree to use a fixed format, > then a bunch of work there that probably has to be done manually can > be automated. However, if we all agree to use a fixed format except > for you, we might as well just forget the whole thing, because the > percentage of commits that are done by you is quite high. Yes, we are either all in or we may as well forgo this. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development.
On 01/28/2016 06:34 AM, Bruce Momjian wrote: > On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote: >> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra >> <tomas.vondra@2ndquadrant.com> wrote: >>>> How about >>>> User-Interface-Bikeshedded-By: >>>> ? >>> >>> +1 >> >> That's sort of implicitly pejorative. Maybe we could find another >> way to phrase that, like "Design-suggestions-by" or maybe a more >> general "Suggestions-by". > > I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch, > or to the discussion of labels for the commit messages. Contribution-by: Definition: Individuals who provided notable review which may or may not have been code review. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development.
* Joshua D. Drake (jd@commandprompt.com) wrote: > On 01/28/2016 06:57 AM, Robert Haas wrote: > > >>I'm on board with Bruce's template as being a checklist of points to be > >>sure to cover when composing a commit message. I'm not sure we need > >>fixed-format rules. > > > >Well, I think what people are asking for is precisely a fixed format, > >and I do think there is value in that. It's nice to capture the > >nuance, but the nuance is going to get flattened out anyway when the > >release notes are created. If we all agree to use a fixed format, > >then a bunch of work there that probably has to be done manually can > >be automated. However, if we all agree to use a fixed format except > >for you, we might as well just forget the whole thing, because the > >percentage of commits that are done by you is quite high. > > Yes, we are either all in or we may as well forgo this. I don't have a particular issue with it, but would like whatever template is decided upon to be included in our git repo and then we should be able to make it the template that's opened up when people go to commit pretty easily. Thanks! Stephen
On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote: > * Joshua D. Drake (jd@commandprompt.com) wrote: > > On 01/28/2016 06:57 AM, Robert Haas wrote: > > > > >>I'm on board with Bruce's template as being a checklist of points to be > > >>sure to cover when composing a commit message. I'm not sure we need > > >>fixed-format rules. > > > > > >Well, I think what people are asking for is precisely a fixed format, > > >and I do think there is value in that. It's nice to capture the > > >nuance, but the nuance is going to get flattened out anyway when the > > >release notes are created. If we all agree to use a fixed format, > > >then a bunch of work there that probably has to be done manually can > > >be automated. However, if we all agree to use a fixed format except > > >for you, we might as well just forget the whole thing, because the > > >percentage of commits that are done by you is quite high. > > > > Yes, we are either all in or we may as well forgo this. > > I don't have a particular issue with it, but would like whatever > template is decided upon to be included in our git repo and then we > should be able to make it the template that's opened up when people go > to commit pretty easily. OK, but keep in mind whatever script committers user should remove tags that are empty after exiting the editor. I can provide the grep regex in git somewhere too: egrep -v "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$" -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On 01/28/2016 03:37 PM, Robert Haas wrote: > On Thu, Jan 28, 2016 at 9:34 AM, Bruce Momjian <bruce@momjian.us> wrote: >> On Thu, Jan 28, 2016 at 09:31:46AM -0500, Robert Haas wrote: >>> On Thu, Jan 28, 2016 at 6:16 AM, Tomas Vondra >>> <tomas.vondra@2ndquadrant.com> wrote: >>>>> How about >>>>> User-Interface-Bikeshedded-By: >>>>> ? >>>> >>>> +1 >>> >>> That's sort of implicitly pejorative. Maybe we could find another >>> way to phrase that, like "Design-suggestions-by" or maybe a more >>> general "Suggestions-by". >> >> I wasn't sure if "User-Interface-Bikeshedded-By" related to the patch, >> or to the discussion of labels for the commit messages. > > I thought it was a proposed commit message label and that the original > suggestion was tongue-in-cheek, but I might be misreading things. Perhaps I'm wrong, but I believe that particular header was not really meant seriously. -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
* Bruce Momjian (bruce@momjian.us) wrote: > On Thu, Jan 28, 2016 at 10:40:09AM -0500, Stephen Frost wrote: > > * Joshua D. Drake (jd@commandprompt.com) wrote: > > > On 01/28/2016 06:57 AM, Robert Haas wrote: > > > > > > >>I'm on board with Bruce's template as being a checklist of points to be > > > >>sure to cover when composing a commit message. I'm not sure we need > > > >>fixed-format rules. > > > > > > > >Well, I think what people are asking for is precisely a fixed format, > > > >and I do think there is value in that. It's nice to capture the > > > >nuance, but the nuance is going to get flattened out anyway when the > > > >release notes are created. If we all agree to use a fixed format, > > > >then a bunch of work there that probably has to be done manually can > > > >be automated. However, if we all agree to use a fixed format except > > > >for you, we might as well just forget the whole thing, because the > > > >percentage of commits that are done by you is quite high. > > > > > > Yes, we are either all in or we may as well forgo this. > > > > I don't have a particular issue with it, but would like whatever > > template is decided upon to be included in our git repo and then we > > should be able to make it the template that's opened up when people go > > to commit pretty easily. > > OK, but keep in mind whatever script committers user should remove tags > that are empty after exiting the editor. I can provide the grep regex > in git somewhere too: > > egrep -v "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$" If the template is there then, for my part at least, I wouldn't mind killing the empty lines. Having a decent script would work too, of course... but I have to admit that I've not tried having a script modify my commit messages right before they're committed and, well, it'd take a bit for me to be comfortable with it. No one wants garbled commit messages from a script that went awry. ;) Thanks! Stephen
On 01/28/2016 09:57 AM, Robert Haas wrote: > On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra >>> <tomas.vondra@2ndquadrant.com> wrote: >>>> Why can't we do both? That is, have a free-form text with the nuances, and >>>> then Reviewed-By listing the main reviewers? The first one is for humans, >>>> the other one for automated tools. >>> I'm not objecting to or endorsing any specific proposal, just asking >>> what we want to do about this. I think the trick if we do it that way >>> will be to avoid having it seem like too much duplication, but there >>> may be a way to manage that. >> FWIW, I'm a bit suspicious of the idea that we need to make the commit >> messages automated-tool-friendly. What tools are there that would need >> to extract this info, and would we trust them if they didn't understand >> "nuances"? >> >> I'm on board with Bruce's template as being a checklist of points to be >> sure to cover when composing a commit message. I'm not sure we need >> fixed-format rules. > Well, I think what people are asking for is precisely a fixed format, > and I do think there is value in that. It's nice to capture the > nuance, but the nuance is going to get flattened out anyway when the > release notes are created. If we all agree to use a fixed format, > then a bunch of work there that probably has to be done manually can > be automated. However, if we all agree to use a fixed format except > for you, we might as well just forget the whole thing, because the > percentage of commits that are done by you is quite high. > Yeah. I have no prejudice in this area, other than one in favor of any rules being fairly precise. As for nuances, I guess they can be specified in the commit message. The one thing I do find annoying from time to time is the limit on subject size. Sometimes it's very difficult to be sufficiently communicative in, say, 50 characters. cheers andrew
Stephen Frost wrote:
> > OK, but keep in mind whatever script committers user should remove tags
> > that are empty after exiting the editor. I can provide the grep regex
> > in git somewhere too:
> >
> > egrep -v "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$"
>
> If the template is there then, for my part at least, I wouldn't mind
> killing the empty lines. Having a decent script would work too, of
> course... but I have to admit that I've not tried having a script modify
> my commit messages right before they're committed and, well, it'd take a
> bit for me to be comfortable with it.
>
> No one wants garbled commit messages from a script that went awry. ;)
Maybe it'd be better to have the lines start with a # , because then
git commit itself removes those as comments. So the committer would
need to remove the # and then fill in the data for the field.
git-commit(1) says:
-t <file>, --template=<file> When editing the commit message, start the editor with the contents
in the given file. The commit.template configuration variable is often used to give this option implicitly to
thecommand. This mechanism can be used by projects that want to guide participants with some hints on
whatto write in the message in what order. If the user exits the editor without editing the message, the
commit is aborted. This has no effect when a message is given by other means, e.g. with the -m or -F
options.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 28, 2016 at 03:16:18PM -0500, Stephen Frost wrote:
> > OK, but keep in mind whatever script committers user should remove tags
> > that are empty after exiting the editor. I can provide the grep regex
> > in git somewhere too:
> >
> > egrep -v "^(Author|Reported-by|Bug|Reviewed-by|Tested-by|Backpatch-through): *$"
>
> If the template is there then, for my part at least, I wouldn't mind
> killing the empty lines. Having a decent script would work too, of
> course... but I have to admit that I've not tried having a script modify
> my commit messages right before they're committed and, well, it'd take a
> bit for me to be comfortable with it.
>
> No one wants garbled commit messages from a script that went awry. ;)
I have always used a script. This removes trailing blank lines:
sed -e :a -e '/./,$!d;/^\n*$/{$d;N;};/\n$/ba'
and this removes adjacent blank lines:
cat --squeeze-blank
I can publish my script at the appropriate time.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote: > I have no prejudice in this area, other than one in favor of any > rules being fairly precise. As for nuances, I guess they can be > specified in the commit message. The one thing I do find annoying > from time to time is the limit on subject size. Sometimes it's very > difficult to be sufficiently communicative in, say, 50 characters. Agreed, but that is a gitweb limit we can't control, I think. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Roman grave inscription +
On 2016-01-29 04:42:08 -0500, Bruce Momjian wrote: > On Thu, Jan 28, 2016 at 07:30:58PM -0500, Andrew Dunstan wrote: > > I have no prejudice in this area, other than one in favor of any > > rules being fairly precise. As for nuances, I guess they can be > > specified in the commit message. The one thing I do find annoying > > from time to time is the limit on subject size. Sometimes it's very > > difficult to be sufficiently communicative in, say, 50 characters. > > Agreed, but that is a gitweb limit we can't control, I think. That's not that hard to change. And neither git nor kernel people use 50 char limits. I'm *strongly* opposed to making 50 chars the limit for the first line.
Andres Freund <andres@anarazel.de> writes:
> That's not that hard to change. And neither git nor kernel people use 50
> char limits. I'm *strongly* opposed to making 50 chars the limit for the
> first line.
Ditto. It's hard enough to fit a useful headline in 75 characters.
I personally will ignore any rule that says it must be even less.
regards, tom lane
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> FWIW, I'm a bit suspicious of the idea that we need to make the commit
>> messages automated-tool-friendly. What tools are there that would need
>> to extract this info, and would we trust them if they didn't understand
>> "nuances"?
> Well, I think what people are asking for is precisely a fixed format,
> and I do think there is value in that. It's nice to capture the
> nuance, but the nuance is going to get flattened out anyway when the
> release notes are created. If we all agree to use a fixed format,
> then a bunch of work there that probably has to be done manually can
> be automated.
I'm not particularly impressed by this argument --- as someone who
regularly prepares release notes, I see exactly zero value in this
to me. I'm willing to go along with it if there's consensus, but the
argument that "Foo: Bar" format has more value than free-form hasn't
actually been made in any form that withstands any skepticism.
In any case, agreeing on a set of "Foo:" keywords isn't nearly enough
to allow any useful automated processing. You have to standardize
the "Bar" part as well, and that hasn't been addressed at all.
Some example questions:
In "Bug:", bug number with or without "#"? What format to use if
there's more than one related bug?
In headers referring to people: name? email? both? what if we have
incomplete information (not unusual in bug reports)? what about
referencing multiple people in same header? what can we do to avoid
variant spellings in different commit messages?
In "Backpatch-through:", how are we to indicate version numbers
exactly? what about special cases such as a patch applied
only to older branches? And perhaps most importantly, why are
we bothering with that at all when git can tell us that much
more reliably? (Personally, I only bother with mentioning this
in the commit message to the extent that I'm explaining *why*
I patched back so far and no further. Which I think is useful
information that a "backpatch-through: N.N" kind of entry would
entirely fail to capture.)
regards, tom lane
On 28 January 2016 15:57:15 CET, Robert Haas <robertmhaas@gmail.com> wrote: >On Thu, Jan 28, 2016 at 9:52 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas@gmail.com> writes: >>> On Thu, Jan 28, 2016 at 8:04 AM, Tomas Vondra >>> <tomas.vondra@2ndquadrant.com> wrote: >>>> Why can't we do both? That is, have a free-form text with the >nuances, and >>>> then Reviewed-By listing the main reviewers? The first one is for >humans, >>>> the other one for automated tools. >> >>> I'm not objecting to or endorsing any specific proposal, just asking >>> what we want to do about this. I think the trick if we do it that >way >>> will be to avoid having it seem like too much duplication, but there >>> may be a way to manage that. >> >> FWIW, I'm a bit suspicious of the idea that we need to make the >commit >> messages automated-tool-friendly. What tools are there that would >need >> to extract this info, and would we trust them if they didn't >understand >> "nuances"? >> >> I'm on board with Bruce's template as being a checklist of points to >be >> sure to cover when composing a commit message. I'm not sure we need >> fixed-format rules. > >Well, I think what people are asking for is precisely a fixed format, >and I do think there is value in that. It's nice to capture the >nuance, but the nuance is going to get flattened out anyway when the >release notes are created. If we all agree to use a fixed format, >then a bunch of work there that probably has to be done manually can >be automated. However, if we all agree to use a fixed format except >for you, we might as well just forget the whole thing, because the >percentage of commits that are done by you is quite high. Before I agree to adding fixed format lines to my commits, I'd like to know exactly what people would want to do with theinformation. "Bunch of work that probably could be automated" doesn't cut it. For example, if I tag someone as "Reviewed-by",does it mean that his name will automatically appear in the release notes? Or if there's a bug, is the reviewerthen somehow responsible for missing it? As a way of saying "thank you", I like a personalised, nuanced, message much better. True, we can do both. A good thing aboutprocessing the commit messages manually e.g for compiling release notes is that there's human judgement on what toinclude. Of course, that's a lot of work. Which is why I'd like to hear from whoever wants to make use of these linesto explain in more detail what information they need, and what they would do with it, to make sure that what we addis actually useful, and that we don't add noise to the commit messages unnecessarily. - Heikki
On 01/29/2016 02:59 AM, Heikki Linnakangas wrote: >> Well, I think what people are asking for is precisely a fixed format, >> and I do think there is value in that. It's nice to capture the >> nuance, but the nuance is going to get flattened out anyway when the >> release notes are created. If we all agree to use a fixed format, >> then a bunch of work there that probably has to be done manually can >> be automated. However, if we all agree to use a fixed format except >> for you, we might as well just forget the whole thing, because the >> percentage of commits that are done by you is quite high. > > Before I agree to adding fixed format lines to my commits, I'd like to know exactly what people would want to do with theinformation. "Bunch of work that probably could be automated" doesn't cut it. For example, if I tag someone as "Reviewed-by",does it mean that his name will automatically appear in the release notes? Or if there's a bug, is the reviewerthen somehow responsible for missing it? > > As a way of saying "thank you", I like a personalised, nuanced, message much better. True, we can do both. A good thingabout processing the commit messages manually e.g for compiling release notes is that there's human judgement on whatto include. Of course, that's a lot of work. Which is why I'd like to hear from whoever wants to make use of these linesto explain in more detail what information they need, and what they would do with it, to make sure that what we addis actually useful, and that we don't add noise to the commit messages unnecessarily. > > - Heikki I think the best question to ask is: "What is the problem we are trying to solve?" "A bunch of work that probably could be automated" Does not answer that question. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development.
Joshua D. Drake wrote: > I think the best question to ask is: > > "What is the problem we are trying to solve?" The problem is alluring more patch reviewers, beta testers and bug reporters. One of the offers is to credit them (I'm not exactly clear on what is the group to benefit from this, but the phrasing used in the meeting was "contributors to the release") by having a section somewhere in the release notes with a list of their names. This proposal is different from the previous proposal because their names wouldn't appear next to each feature. So the problem, of course, is collating that list of names, and the point of having a commit template is to have a single, complete source of truth from where to extract the info. 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.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: >> I think the best question to ask is: >> >> "What is the problem we are trying to solve?" > > The problem is alluring more patch reviewers, beta testers and bug > reporters. One of the offers is to credit them (I'm not exactly clear > on what is the group to benefit from this, but the phrasing used in the > meeting was "contributors to the release") by having a section somewhere > in the release notes with a list of their names. This proposal is > different from the previous proposal because their names wouldn't appear > next to each feature. > > So the problem, of course, is collating that list of names, and the > point of having a commit template is to have a single, complete source > of truth from where to extract the info. > > 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. So even if we all agreed in principle to a standard format, it's not clear that you could enforce compliance with that format to a degree sufficient to make machine-parseability a reality. But let's say you could somehow make it so that every commit message was machine-parseable. Then you could write a script which went through the commit log since the branch point for the prior release and extracted every name listed as a reviewer and printed them all out. Then you could put that in the release notes or on the project web site someplace and say "The PostgreSQL Project thanks the following list of people for reviewing patches during the 9.23 release cycle". Doing that same thing without machine-parseable commit messages can of course also be done, but it's going to require somebody to manually review every commit, which is a lot more work. Similarly, you could do write a script to do things like "show me all patches with person X as an author". Right now that's actually kind of hard to do, especially if that author happens to be a committer. Or you could write a script to print out all commits from the last week in the format: COMMITTER committed a patch from AUTHOR to do SUMMARY, and then you could stick that into PWN, again instead of having to do it by manually reviewing the commit message. I'm not sure that those benefits are sufficient to justify the hassle of trying to make a fixed template work. But I think it's a little strange to hear a bunch of people whose develop the world's most advanced open source relational database system argue that structured data is an intrinsically unused thing to have, and therefore we should just store all of our information freeform in one very wide text column. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas wrote: > On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera > <alvherre@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. 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. (*) 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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Sat, Jan 30, 2016 at 5:22 AM, Alvaro Herrera <alvherre@2ndquadrant.com> wrote: > Robert Haas wrote: >> On Fri, Jan 29, 2016 at 6:05 PM, Alvaro Herrera >> <alvherre@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
On 30 January 2016 at 05:11, Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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. So even if we
> all agreed in principle to a standard format, it's not clear that you
> could enforce compliance with that format to a degree sufficient to
> make machine-parseability a reality.
Yep, there's the rub in it.>
> 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. So even if we
> all agreed in principle to a standard format, it's not clear that you
> could enforce compliance with that format to a degree sufficient to
> make machine-parseability a reality.
constructed something a wee bit too fragile.
A thing plausible instead is to collect the authoritative-at-commit-time
message information into an external system (hey, I wonder if anyone
has some sort of structured data store implemented that could be
good at this!), and then have a way to feed additional information into
that system that would become the authoritative source for any
requirements for the extra metadata.
That, of course, smells like a database that draws metadata from git,
and augments with further streams of inputs. There is certainly
something problematic about assuming that we can *always* get
supplementary data. Begs the question of how we shame people
into going back and filling the blanks we wanted filled.
It seems foolish to me to imagine that we can ensure that the
data *always* arrives at commit time; any laziness there represents
a permanent "data fault"; making it asynchronous shifts the problem
to a different spot. I suspect we can only approach success on it,
and get *partial* metadata, at best. If it's enough better than nothing,
then maybe that's good enough. And I'll bet that the Commitfest
database already contains a lot of the data desired to fill blanks...
Further, if the point is to encourage reviews by making sure credit
(and hence data to support GIVING credit) is given, then it is not
inapropos for those keen on receiving credit to be responsible for
marking off the patches they know they contributed to. That's
less fragile than expecting all credit to be attached by the
committer at commit time.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"
On 01/29/2016 03:05 PM, Alvaro Herrera wrote: > Joshua D. Drake wrote: > >> I think the best question to ask is: >> >> "What is the problem we are trying to solve?" > > The problem is alluring more patch reviewers, beta testers and bug > reporters. Do we really want patch reviewers, beta testers and bug reporters that are doing it because we created a fixed template for commit messages that may mention their name? > One of the offers is to credit them (I'm not exactly clear > on what is the group to benefit from this, but the phrasing used in the > meeting was "contributors to the release") by having a section somewhere > in the release notes with a list of their names. I can see this as being a nice thing but knowing that someone is a contributor isn't hard. There is a contributor list on the website and it is obvious from mail lists, archives and simple searches who is actually participating. > This proposal is > different from the previous proposal because their names wouldn't appear > next to each feature. That certainly is a good thing. > > So the problem, of course, is collating that list of names, and the > point of having a commit template is to have a single, complete source > of truth from where to extract the info. > I think the problem is that we think that this is somehow going to allure more people. I also think it is a quick step from: Oh, Alvaro helped a lot with that. vs On, 2Q wrote that feature. Any smart business is going to push for that once we start down this path in earnest. Sincerely, Joshua D. Drake -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development.
Joshua D. Drake wrote: > On 01/29/2016 03:05 PM, Alvaro Herrera wrote: > >Joshua D. Drake wrote: > > > >>I think the best question to ask is: > >> > >>"What is the problem we are trying to solve?" > > > >The problem is alluring more patch reviewers, beta testers and bug > >reporters. > > Do we really want patch reviewers, beta testers and bug reporters that are > doing it because we created a fixed template for commit messages that may > mention their name? We want *some* patch reviewers and beta testers. We don't really care what's their motivation, as long as their do their thing. The motivating factor is supposed to be getting credit -- not in the commit messages (because other people don't look at those) but having their names appear in the release notes. > >One of the offers is to credit them (I'm not exactly clear > >on what is the group to benefit from this, but the phrasing used in the > >meeting was "contributors to the release") by having a section somewhere > >in the release notes with a list of their names. > > I can see this as being a nice thing but knowing that someone is a > contributor isn't hard. There is a contributor list on the website and it is > obvious from mail lists, archives and simple searches who is actually > participating. It's not obvious, which is why this is being discussed at all, and the contributor list in the website is useless for the purposes at hand. And it is hard, which is why the issue was raised in the first place -- heck, when this was mentioned, somebody said "but we would have to wait until 9.7 because we don't have that information in existing commit messages in 9.6 already" (he was promptly made to shut up, because most if not all committers are already crediting reviewers in their commit messages and we don't want to wait *two years* to implement this idea.) > >So the problem, of course, is collating that list of names, and the > >point of having a commit template is to have a single, complete source > >of truth from where to extract the info. > > I think the problem is that we think that this is somehow going to allure > more people. How come the issue of crediting people comes up so often, if it is, as you seem to be saying, so worthless? > I also think it is a quick step from: > > Oh, Alvaro helped a lot with that. > > vs > > On, 2Q wrote that feature. I'm not sure what's your point here, but the release notes are going to list individuals, not companies. (FWIW if it were up to me committers and major contributors would not be in the list anyway.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote: > On 01/29/2016 03:05 PM, Alvaro Herrera wrote: >> Joshua D. Drake wrote: >> One of the offers is to credit them (I'm not exactly clear >> on what is the group to benefit from this, but the phrasing used in the >> meeting was "contributors to the release") by having a section somewhere >> in the release notes with a list of their names. > > > I can see this as being a nice thing but knowing that someone is a > contributor isn't hard. There is a contributor list on the website and it is > obvious from mail lists, archives and simple searches who is actually > participating. This page would need a refresh IMO. I think it has not been touched for the last couple of years. -- Michael
On 01/31/2016 04:34 PM, Michael Paquier wrote: > On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote: >> On 01/29/2016 03:05 PM, Alvaro Herrera wrote: >>> Joshua D. Drake wrote: >>> One of the offers is to credit them (I'm not exactly clear >>> on what is the group to benefit from this, but the phrasing used in the >>> meeting was "contributors to the release") by having a section somewhere >>> in the release notes with a list of their names. >> >> >> I can see this as being a nice thing but knowing that someone is a >> contributor isn't hard. There is a contributor list on the website and it is >> obvious from mail lists, archives and simple searches who is actually >> participating. > > This page would need a refresh IMO. I think it has not been touched > for the last couple of years. No doubt but if we can't bother to keep that refreshed what makes us think that a structured format in commit messages that magically (through a lot of hard work and extra parsing anyway) is going to be any more accurate? Sincerely, JD > -- Command Prompt, Inc. http://the.postgres.company/ +1-503-667-4564 PostgreSQL Centered full stack support, consulting and development.
Sorry for little late.
Can we add Severity level of patch? with only three levels as (High, Moderate, Low)
Many of our customers might not understand overall important of patch.
If we add this people/customers can choose patch is important for them or not.
Other than Author and hackers can not easily understand overall importance of patch.
Please consider if you feel it is important to add this parameter in commit message format.
On Mon, Feb 1, 2016 at 10:04 AM, Joshua D. Drake <jd@commandprompt.com> wrote:
On 01/31/2016 04:34 PM, Michael Paquier wrote:On Mon, Feb 1, 2016 at 2:44 AM, Joshua D. Drake wrote:On 01/29/2016 03:05 PM, Alvaro Herrera wrote:Joshua D. Drake wrote:
One of the offers is to credit them (I'm not exactly clear
on what is the group to benefit from this, but the phrasing used in the
meeting was "contributors to the release") by having a section somewhere
in the release notes with a list of their names.
I can see this as being a nice thing but knowing that someone is a
contributor isn't hard. There is a contributor list on the website and it is
obvious from mail lists, archives and simple searches who is actually
participating.
This page would need a refresh IMO. I think it has not been touched
for the last couple of years.
No doubt but if we can't bother to keep that refreshed what makes us think that a structured format in commit messages that magically (through a lot of hard work and extra parsing anyway) is going to be any more accurate?
Sincerely,
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Sachin Kotwal
Joshua D. Drake wrote: > On 01/31/2016 04:34 PM, Michael Paquier wrote: > >This page would need a refresh IMO. I think it has not been touched > >for the last couple of years. > > No doubt but if we can't bother to keep that refreshed what makes us think > that a structured format in commit messages that magically (through a lot of > hard work and extra parsing anyway) is going to be any more accurate? If you're proposing to keep that page updated, please propose that in pgsql-www instead of hijacking this thread. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
<div dir="ltr"><br /><div class="gmail_extra"><br /><div class="gmail_quote">On Mon, Feb 1, 2016 at 6:13 PM, Alvaro Herrera<span dir="ltr"><<a href="mailto:alvherre@2ndquadrant.com" target="_blank">alvherre@2ndquadrant.com</a>></span>wrote:<br /><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px#ccc solid;padding-left:1ex"><span class="">Joshua D. Drake wrote:<br /> > On 01/31/2016 04:34 PM,Michael Paquier wrote:<br /><br /></span><span class="">> >This page would need a refresh IMO. I think it has notbeen touched<br /> > >for the last couple of years.<br /> ><br /> > No doubt but if we can't bother to keepthat refreshed what makes us think<br /> > that a structured format in commit messages that magically (through a lotof<br /> > hard work and extra parsing anyway) is going to be any more accurate?<br /><br /></span>If you're proposingto keep that page updated, please propose that in<br /> pgsql-www instead of hijacking this thread.<br /></blockquote></div><br/></div><div class="gmail_extra">Oops. Sorry about that.<br />-- <br /><div class="gmail_signature">Michael<br/></div></div></div>
On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote: > Reported-by: > Bug: > Author: > Reviewed-by: > Tested-by: > Backpatch-through: I personally, and I realize that I'm likely alone on that, would really like to see references to relevant threads. A year after a commit or such it often starts to get hard to know which threads a commit was about. Often it's easy enough if it's about a single feature, but bugfixes often originate in threads that have no directly corresponding thread. And often the commit happens a while after there's been activity in a thread. I spent days searching what thread "per discussion" in commit messages refers to.
On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund <andres@anarazel.de> wrote: > I personally, and I realize that I'm likely alone on that, would really > like to see references to relevant threads. A year after a commit or > such it often starts to get hard to know which threads a commit was > about. Often it's easy enough if it's about a single feature, but > bugfixes often originate in threads that have no directly corresponding > thread. And often the commit happens a while after there's been activity > in a thread. I spent days searching what thread "per discussion" in > commit messages refers to. +1. Having to look at the archives to find to which discussion a commit is attached is a pain. Last time this was suggested though there were concerns regarding the 72-80 character limit per line in a commit message. -- Michael
On Mon, Feb 1, 2016 at 12:53 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Mon, Feb 1, 2016 at 8:36 PM, Andres Freund <andres@anarazel.de> wrote:
> I personally, and I realize that I'm likely alone on that, would really
> like to see references to relevant threads. A year after a commit or
> such it often starts to get hard to know which threads a commit was
> about. Often it's easy enough if it's about a single feature, but
> bugfixes often originate in threads that have no directly corresponding
> thread. And often the commit happens a while after there's been activity
> in a thread. I spent days searching what thread "per discussion" in
> commit messages refers to.
+1. Having to look at the archives to find to which discussion a
commit is attached is a pain. Last time this was suggested though
there were concerns regarding the 72-80 character limit per line in a
commit message.
Let's just assume that we can fix that part. As in, we can expose either an internal db id or a short hash or something, from the archives server. We could then have that visible/linkable directly on the archives page, and one could copy/paste that link into the commit message. That way we can avoid the long messageids.
On 2016-02-01 20:53:56 +0900, Michael Paquier wrote: > Last time this was suggested though there were concerns regarding the > 72-80 character limit per line in a commit message. That seems like a misdirect. The limit is there to keep things readable, not because there's a hard technical limit. So if a messageid is longer, it doesn't have much consequence. Andres
On 01/02/16 13:36, Andres Freund wrote: > On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote: >> Reported-by: >> Bug: >> Author: >> Reviewed-by: >> Tested-by: >> Backpatch-through: > > I personally, and I realize that I'm likely alone on that, would really > like to see references to relevant threads. A year after a commit or > such it often starts to get hard to know which threads a commit was > about. Often it's easy enough if it's about a single feature, but > bugfixes often originate in threads that have no directly corresponding > thread. And often the commit happens a while after there's been activity > in a thread. I spent days searching what thread "per discussion" in > commit messages refers to. +1. I also quite often look at a commit message, and then hunt the "per discussion". A message-id would save some time there. I've seen you add annotations like that to your commits, which is nice. I'll start doing that myself. You've used the "Discussion: <message-id>" format for that, so I'll go with that too. (Even if the message-id is given in free-form in the paragraphs, that's helpful, but might as well use a fixed form.) And that's a proposal that's not "we must all do it or it's useless". If half of commit messages include that, then hunting the "per discussion" for those commits becomes easier, and the rest are the same as now. - Heikki
On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote: > Let's just assume that we can fix that part. As in, we can expose either an > internal db id or a short hash or something, from the archives server. We > could then have that visible/linkable directly on the archives page, and > one could copy/paste that link into the commit message. That way we can > avoid the long messageids. Raw messageids have the big big advantage that you can get them locally in your mailreader, and you can dereference them locally... I type esc-X id:$id<enter> and 20ms later I have the whole thread open. Maybe I just travel too much, but travel time is often long and uninterrupted and thus pretty nice to work on patches. I don't really see the problem, even with gmail style messageids Discussion: CABUevEz_UJA0ddrW7apjh3Nm4p0KghwOPm0WPW4Mh_gT2-nRJw@mail.gmail.com isn't that bad. Andres
Andres Freund wrote: > On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote: > > Let's just assume that we can fix that part. As in, we can expose either an > > internal db id or a short hash or something, from the archives server. We > > could then have that visible/linkable directly on the archives page, and > > one could copy/paste that link into the commit message. That way we can > > avoid the long messageids. > > Raw messageids have the big big advantage that you can get them locally > in your mailreader, and you can dereference them locally... I type > esc-X id:$id<enter> and 20ms later I have the whole thread open. Yes, +1 on that. > Maybe I just travel too much, but travel time is often long and > uninterrupted and thus pretty nice to work on patches. I don't travel as much as you or Magnus do (!) but I do offline work a lot, so I appreciate full message-ids. > I don't really see the problem, even with gmail style messageids > Discussion: CABUevEz_UJA0ddrW7apjh3Nm4p0KghwOPm0WPW4Mh_gT2-nRJw@mail.gmail.com > isn't that bad. Yes, yes, I prefer to use the full URL because then a machine can tell whether it's an email address and not a message-id, which is useful for mangling addresses while at the same time not mangling message-ids. But I'm not going to force that on anybody. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Mon, Feb 1, 2016 at 1:04 PM, Andres Freund <andres@anarazel.de> wrote:
On 2016-02-01 12:56:21 +0100, Magnus Hagander wrote:
> Let's just assume that we can fix that part. As in, we can expose either an
> internal db id or a short hash or something, from the archives server. We
> could then have that visible/linkable directly on the archives page, and
> one could copy/paste that link into the commit message. That way we can
> avoid the long messageids.
Raw messageids have the big big advantage that you can get them locally
in your mailreader, and you can dereference them locally... I type
esc-X id:$id<enter> and 20ms later I have the whole thread open. Maybe
I just travel too much, but travel time is often long and uninterrupted
and thus pretty nice to work on patches.
If it was a short hash of the same thing, you could equally find them locally though, couldn't you?
I don't really see the problem, even with gmail style messageids
Discussion: CABUevEz_UJA0ddrW7apjh3Nm4p0KghwOPm0WPW4Mh_gT2-nRJw@mail.gmail.com
isn't that bad.
If people don't actually have a problem with it, that of course makes it even easier :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 FWIW, I read the git logs quite a bit, especially after a release to gather some stats, and I *love* the commits that have some nice standard, easy to read fields (Alvaro for one does a great job at this). I don't think we need to mandate it, or even ensure they are machine-parseable, but I would like to see a few fields encouraged. I think it also helps the committers to not forget some important things, the way the free-form text can. tl;dr be like Alvaro, please - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201602011037 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAlavfNwACgkQvJuQZxSWSsg4YgCgmWoL38qljypgUn082aWVp4y8 WDsAn24IwFKwqaudYRF1e3rvd0yz5btw =2Jc2 -----END PGP SIGNATURE-----
On Mon, Feb 01, 2016 at 01:55:23PM +0200, Heikki Linnakangas wrote: > On 01/02/16 13:36, Andres Freund wrote: > >On 2016-01-28 06:03:02 -0500, Bruce Momjian wrote: > >> Reported-by: > >> Bug: > >> Author: > >> Reviewed-by: > >> Tested-by: > >> Backpatch-through: > > > >I personally, and I realize that I'm likely alone on that, would really > >like to see references to relevant threads. A year after a commit or > >such it often starts to get hard to know which threads a commit was > >about. Often it's easy enough if it's about a single feature, but > >bugfixes often originate in threads that have no directly corresponding > >thread. And often the commit happens a while after there's been activity > >in a thread. I spent days searching what thread "per discussion" in > >commit messages refers to. > > +1. I also quite often look at a commit message, and then hunt the "per > discussion". A message-id would save some time there. +1