Hi Jim, Karl, On 1 Nov 2011, at 20:13, Jim Meyering wrote: > Gary V. Vaughan wrote: >> >> diff --git a/ChangeLog b/ChangeLog >> index f370be6..d59d9f9 100644 >> --- a/ChangeLog >> +++ b/ChangeLog >> @@ -1,5 +1,14 @@ >> 2011-11-01 Gary V. Vaughan <g...@gnu.org> >> >> + gitlog-to-changelog: support `tiny change' commits. >> + The FSF insist that all non-trivial patches to its projects are > > Even if somewhere you've felt "insistence" on this issue, > let's just write "request": > > s/insist/request/ > > s/are/be/ (both above and below) > >> + accompanied by appropriate paperwork, or that any patches that are >> + applied without that paperwork are marked as such in the >> + ChangeLog. >> + * gitlog-to-changelog: Convert `Copyright-paperwork-required: No' > > I find that rather long, and have a slight preference > to avoid an always-negative setting.
Sure, I cribbed this from the boilerplate email that Ralf (Wildenhues) sends off list to submitters of large patches that we'd like to commit, but which are too large to be considered trivial enough to use without paperwork. > Did you consider "Tiny-change: Yes" > or even simply "/^Tiny[- ]change\b/", I did consider, but the whole Tiny Change terminology seems anachronistic to me. Although we have long settled on the unfortunate convention of annotating ChangeLog entries with "(tiny change)" whenever a patch is considered by the committer to be trivial enough not to require an exchange of copyright paperwork, I think it is clearer and more sensible to state that directly than be forever explaining to patch submitters that we're not belittling their contribution, but merely noting that we don't require them to file a copyright disclaimer. I chose the negative version to optimise for frequency. I would hate to have to add 'Copyright-paperwork-on-file: Yes' to almost every patch. I guess I'd be happy with 'Copyright-paperwork-not-required: .*$', if it's just the 'No' that you dislike... although it feels a lot more awkward to write 'xxx-not-required: Yes' than a simple 'xxx-required: No'. > so that "Tiny change by ..." will be recognized. I actually dislike the 'Tiny change' misnomer, and would love to take this opportunity to choose a more descriptive and clear annotation for git logs, while still respecting the established ChangeLog standards in dist tarballs. > Now that I've thought about it a little more, ... > > Actually, I question whether establishing such a convention. > and going to this trouble is worthwhile, since the size of the > change is already known, via the associated patch. This is a confusion brought about by the 'Tiny change' misnomer I think. If it were a simple matter of counting lines, then you would be entirely correct of course, but what about a refactoring that moves code around considerably and generates a huge patch, potentially with a large difference between number of lines added vs number of lines removed, even though no new code is added? That would certainly qualify for 'Copyright-paperwork-required: No'/'tiny change'. > The notation requirement made more sense back each ChangeLog entry > was not tied to the associated patch. Before modern VCS you mean? That's before my time then... even CVS still ties the ChangeLog to the patch does it not? Or do you mean in a dist tarball, in which case git history is not supplied, so there is no tie there either, which is why we still distribute ChangeLogs, I think... > Authorship matters a lot more than marking a change > that is obviously small by some measure as a "(tiny change)". Agreed. However, Libtool has made considerable effort to keep track of assignments and (tiny change) annotations, so at the very least we'll need to keep this or something similar in gnulib-local patches before moving generating ChangeLog from git logs at distribution time. This patch doesn't enforce any requirement to set annotations in git log messages, but provides the means to do so for the projects that want or need it without local patching. It would be nicer for those projects to centralise the annotation in gnulib, than to each research and invent their own mechanism (as I have essentially just done for Libtool). The other thing I considered, which is not necessary for Libtool (although we would use it over rolling our own if gnulib prefers this route), is to use git notes to add the metadata to each commit. This would allow us to go back through history and add notes as necessary that gitlog-to-changelog would generate a full ChangeLog (without loss of multiple authors and tiny changes) right back to the start of the project, without messing up the SHA1 sums on each node in the changeset tree. In some ways that is more appealing, but I worry that the notes might get lost in merge, or forged somehow since they are essentially out-of-band. Putting the annotations directly into the git commit message avoids those worries, at the expense of only being applicable moving forwards in time from when they are adopted. > Let's see what Karl thinks. Ack. Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)