From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Your commit 7409a79 Date: Tue, 09 Dec 2014 18:57:07 +0200 Message-ID: <83mw6wwyl8.fsf@gnu.org> References: <83h9x917il.fsf@gnu.org> <85k324h0hg.fsf@stephe-leake.org> <83k324yv44.fsf@gnu.org> <85tx17dqzy.fsf@stephe-leake.org> <83y4qixhq8.fsf@gnu.org> <85r3w9bu3y.fsf@stephe-leake.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1418144277 2302 80.91.229.3 (9 Dec 2014 16:57:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Dec 2014 16:57:57 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 09 17:57:48 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XyO6e-00038F-FT for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 17:57:48 +0100 Original-Received: from localhost ([::1]:41347 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyO6e-0004ia-53 for ged-emacs-devel@m.gmane.org; Tue, 09 Dec 2014 11:57:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyO6H-0004hJ-IO for emacs-devel@gnu.org; Tue, 09 Dec 2014 11:57:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyO67-0007LR-FA for emacs-devel@gnu.org; Tue, 09 Dec 2014 11:57:25 -0500 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:52686) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyO67-0007LE-6U for emacs-devel@gnu.org; Tue, 09 Dec 2014 11:57:15 -0500 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0NGB00J00QYBI100@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Tue, 09 Dec 2014 18:57:13 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NGB00GQ0R3DRQ50@a-mtaout22.012.net.il>; Tue, 09 Dec 2014 18:57:13 +0200 (IST) In-reply-to: <85r3w9bu3y.fsf@stephe-leake.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.172 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:179570 Archived-At: > From: Stephen Leake > Date: Mon, 08 Dec 2014 17:27:13 -0600 > > I have been trying for 30 years to make myself write caps and > periods in commit messages, and it just doesn't work for me (mostly > because I just don't see it as important). Hence the barrier to > contributing. Nothing a simple Lisp function couldn't handle, if installed as a hook in a proper place, right? And the period is no longer an issue, so you are down to caps. > > There was no reprimand in what I wrote, just good will and good > > advice. > I got the impression of "if you don't follow this advice, your commits > will be rejected/not taken seriously". That's _not_ from your text, just > from your position of core developer, and mine as Emacs newbie. And > because there is no clear documentation of what the standards are. Relax, this ain't NASA, and I'm not your boss ;-) I do expect my advice to carry some weight, but not enough to prevent you from arguing if you feel strong about not using caps (or whatever is the issue at hand). > > Note the "merge-commit" alternative above: it would have solved the > > renaming issue (if you even perceive it as an issue: many Git users > > don't, and evidently neither do Git developers). > > As I understand it, by "merge-commit", you mean : > > - create a feature branch > > - On the feature branch, commit the rename without any changes > > - make other changes on the feature branch > > - merge the feature branch to trunk, squashing the commits into one. The "squashing" part is optional. Personally, I prefer not to (if nothing else, it makes bisecting more accurate, and also lets me recall what I've done and why more easily), although the benefits are minor, and some people do prefer squashing. > But "squash all the commits into one" means the Git rename hueristic has > to cope with the changes, which is what I was trying to avoid. Then don't squash. It's not required. The single merge-commit is good enough to make this a single changeset, from the mainline POV. > > CONTRIBUTE: Moved from etc/CONTRIBUTE. > > > > This is in preparation for restructuring of developer contribution > > documents; see http:/ for the related discussion, > > and see http:/ for the decision to move the file. > > > > This has a short summary line which tells enough in "git log" short > > formats, and then the details below, including the rationale. > > > > But this all is a creative, stylistic issue, not something to be > > codified in mandatory documents. There is no single solution to this; > > as long as people choose a reasonable one, and don't goof with > > misspellings or missing punctuation, they should be OK. > It's a big stretch to go from the examples in the Gnu coding standards > to this example. There are some like this in ./Changelog; first one > 2014-11-11 Eric S. Raymond , and that has a leading > asterisk on the first line. Asterisks come from add-change-log-entry and friends, so it will not be there if you just write free text, like I did above. In any case, the asterisks are optional, IMO. They don't carry any information with them. I've been deleting them until now, but I hear some people want to keep them. Other projects are inconsistent wrt this, although most of those I looked at do leave the asterisks alone, probably because it's easier. > It's my impression that it is exactly this kind of style issue that > started this whole thread, so I'd like to have at least a statement of > what will be accepted in CONTRIBUTE. >From experience, the rules are not rigid. You need to put the right information there, and make it in correct English, and that's about all that's really required. Beyond that, it's all about your perfectionism. > How about: > > - The summary line is limited to 72 characters (enforced by a commit > hook). If you have trouble making that a good summary, add a > paragraph below it, before the individual file descriptions. > > - If only a single file is changed, the summary line be the normal file > first line (starting with the asterisk). Then there is no individual > files section. Should be fine. > +- merge the feature branch to trunk, squashing the commits into one. I'd suggest "optionally squashing the commits". Thanks.