provide copy/pasteable template for cvs commit message

if this would help people become consistent with the commit messages, i'm in favor. (that's still an "if" in my mind, since i'm not sure committers would use this, but who knows).

when i looked at this before, one problem is there's no bluebeach template file for issue nodes. so, either we'd have to create one, or, we'd have to special-case this in the regular node template and test the node type.

also, i'm a little bit worried about confusion this would cause to end users of the issue queue. ideally, we'd only show this box to users with commit access to the given project. ;) that's certainly possible, but then we'd be doing another query on viewing an issue, *and* we'd be doing the query at the theme layer, which is kinda ugly if we stick with this approach. so, perhaps we just need a more verbose title for the box than "Commit message"...

For the commit info to be standardized, we can just add a CVSROOT/rcstemplate file with things like issue #, description, and credits.

This would go a long away for prompting users for the correct info to enter in commit messages.

Here is an example from PostgreSQL. Too verbose perhaps, but gives you an idea of what it can do, and instructions can be added in the CVS lines. Another example from FreeBSD.

Gregg

The whole idea is that this file be placed on the cvs server (by dww), and that will automatically make a template pop up for every commit for everyone from now on.

There is no need to hunt for the template on drupal.org, nor there is a need to copy and paste. It will be there by default.

So, it addresses 1 and 2.

The only thing I am not sure about is whether GUI clients (Tortoise et al) will pick it up. They should, but I am not sure.

How about dww modifying that file TODAY by adding a line at the very bottom starting with CVS and having "template test" in it. Then we commit stuff to the sandbox and see if we get it.

@kbahey, a few problems with that approach:

1. those templates don't show up for people (like me) who compose the commit messages in a file, and then do cvs commit -m "`cat cvs.txt`". this makes it easier for me to share the same commit message across multiple branches when backporting (something i do a lot), and allows me to format the commit message as i'm getting everything ready, instead of while i've got the commit in progress...
2. the template won't already have the issue nid and title filled in automatically, which is part of what greggle's approach is trying to accomplish...
3. yeah, all the GUI clients are probably going to handle it differently. :( basically, if your CVS client (be it the CLI, or a GUI) opens up the commit directly from the CVS server, the template will work. if the client composes the commit message in its own world, then sends that over to the server automatically (like I do with the CLI, and like most, if not all, GUIs are probably doing), then it won't work.

The BSD example is:

PR:Submitted by:Reviewed by:Approved by:Obtained from:MFC after:Security:CVS: ----------------------------------------------------------------------
CVS: PR:              Fill this in if a GNATS PR is affected by the change.
CVS: Submitted by:    Fill this in if someone else sent in the change.
CVS: Reviewed by:     Fill this in if someone else reviewed your modification.
CVS: Approved by:     Fill this in if you needed approval for this commit.
CVS: Obtained from:   Fill this in if the change is from third party software.
CVS: MFC after:       N [day[s]|week[s]|month[s]]
CVS:    Fill in to get MFC notification later. (days assumed unless specified)
CVS: Security:        vulnerability reference or description
CVS:    If the change is related to a security vulnerability, include one or
CVS:    more references (e.g. CVE names, VuXML IDs, URLs) or a description
CVS:    of the issue.  Please use one `Security:' entry per reference.

So the Drupal version can be:

#NID by USERNAME, TITLE
----------------------------------------------------------------------
CVS: This line and all lines starting with CVS: will not be included in the commit.
CVS:
CVS: Please read the following carefully to fill the template
CVS:
CVS: NID      The node ID of the issue that is being solved by this commit.
CVS: USERNAME The Drupal.org username of the person submitting the patch, if any.
CVS: TITLE    The title of the issue.
CVS: 
CVS: Example:
CVS: #123456 by somebody, Fix duplicate title issue in foo.module

This will not be autofilled from the issue, but would be nice to have. Even if the instructions
is the only part we add, saying: recommended format. This can be implemented in addition
to the template that is generated by drupal.org.

also, we used to use templates like these at my day job, but another hidden problem with them is that sometimes people would open their commit in an editor that wrapped lines agressively, and then the message was full of template cruft since they didn't notice (or care) that the CVS: stuff wasn't at the front of a line anymore, etc, etc. so, we just ripped them out completely, since they were generating more noise than the signal they were trying to encourage. :(

given the level of CVS experience across the contrib repo, i'm sure we'd have even worse results here...

Hm. Not sure about this idea. Often times I'll try and just re-roll a patch to keep it going... I wouldn't want to accidentally get credit for a patch I didn't author, which seems far more likely in this system. So that would in turn make me less likely to re-roll patches and leave it to the original author to do so, which reduces collaboration in the issue queue...

Plus, commiters really need to read the entire issue anyway (or at least scan it) in order to get the jist of what exactly it is they're contributing. This shortcut seems unnecessary, because you're going to have to edit it anyway when various people collaborate, or to add more details about the implications of a patch. ("patch #232344 by foo, bar, and baz. Does stuff. Make sure to do this other stuff from now on!")

I personally don't find formating commit messages so difficult that it requires such a system. I guess the argument could be made that it saves time on a run-of-the-mill patch that only has one participant and is a straight-forward fix, but most commits just aren't like that, in my experience.

I agree that this is a nice idea and better cvs messages are very welcome, but it is likely to cause more trouble than use. Many people are using a graphical cvs client and/or an editor to write one message for multiple commits to different branches. I'm all for verbose cvs logs, but developers should have the freedom to choose their favorite tools ...

I'm also not convinced that the format used in Drupal core (#12345 by user, message) is best for contrib. There are many commits for contributed modules/themes that do not have an issue/node assigned. Module developers implement new features and commit them directly. That happens (far) more frequent than bugfixes or requested updates, I think. I'm using messages in the following format:
- task/feature/bugfix: message (#12345 credit)
What means the optional "parameters" (like related issue/node and user/credit) are at the end ... There is no mechanism that takes advantage of uniform messages in core/contrib AFAIK. The only purpose of this discussion is to get more verbose messages from the committers, right? That should be encouraged, but not enforced. A "copy/pasteable template at the bottom" is more reasonable than a rcstemplate IMO.

@webchick: look at the code in #1 carefully. the "UserNamesOfPatchAuthors" is a string literal. the committer would have to change that anyway. we all agree the committer has to do *some* work for this. it's just that it would a) include the nid and title automatically and b) encourage them to use a consistent format (that includes crediting the patch authors).

@profix898: if the template is showing up at the bottom of an issue, than certainly we already have an issue nid. ;) furthermore, i'd rather see more contrib authors make issues for their own features and fixes, so there's a place for people to see what's happening, further discuss the changes, etc, etc. yes, the goal is to standardize the commit messages, so they're easy to read and understand, and so that they tend to include all the information they should. in the case of a #nid, that's info that *should* be there, more often than not, so we should encourage people to include it.

Content should not be added via the theme. A module should add this.

Dreditor takes care of this now. Closing.