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: [Emacs-diffs] master b6610d5 2/4: emacs-lisp/package.el: Refactor pre-execute prompt Date: Mon, 06 Apr 2015 17:15:14 +0300 Message-ID: <83r3rxjqbx.fsf@gnu.org> References: <20150406102057.929.89886@vcs.savannah.gnu.org> <5522653C.5010608@yandex.ru> <837ftpldok.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1428329743 28345 80.91.229.3 (6 Apr 2015 14:15:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Apr 2015 14:15:43 +0000 (UTC) Cc: emacs-devel@gnu.org To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 06 16:15:36 2015 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 1Yf7oO-000319-30 for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 16:15:36 +0200 Original-Received: from localhost ([::1]:40273 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf7oN-0006JO-8n for ged-emacs-devel@m.gmane.org; Mon, 06 Apr 2015 10:15:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf7o2-0006JJ-Pd for emacs-devel@gnu.org; Mon, 06 Apr 2015 10:15:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yf7ny-0000h8-KG for emacs-devel@gnu.org; Mon, 06 Apr 2015 10:15:14 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:49497) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yf7ny-0000gz-Cf for emacs-devel@gnu.org; Mon, 06 Apr 2015 10:15:10 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0NME0040022D1600@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Mon, 06 Apr 2015 17:15:09 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NME004W22980X00@a-mtaout23.012.net.il>; Mon, 06 Apr 2015 17:15:09 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 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:185035 Archived-At: > Date: Mon, 6 Apr 2015 15:01:22 +0100 > From: Artur Malabarba > Cc: emacs-devel > > > I actually don't understand why those changes were pushed piecemeal, > > and not as a single commit. They sound like a single changeset to me. > > There are many ways to divide changes into changesets. Sorry if mine > was a little too detailed. The way I learned to do DVCS was to make > commits small enough to be human-readable, but large enough that each > one corresponds to a full working state (all tests passing, etc). What's below follows my personal preferences, so please don't take it as a mandatory requirement of some sort, just food for thought. > Each one of these commits makes a significant change to at least 2 > functions, and I found them hard to read in a single commit so I split > into a few. (In retrospect, the "package-install" commit turned out a > bit trivial, and could be part of another one). What I would do in this situation is work on a branch, make fine-grained commits there, and then merge them all onto master in a single merge-commit. Then, if someone follows first-parent, they'd see a single commit with the feature, while still being able to discern the separate commits you made during development. IOW, I personally prefer not to see partial commits when I follow first-parents. > Do we have an objective definition of what a changeset should be? No, it's a judgment call. For me, an important question that helps the decision is "will I ever want to revert that single changeset?" YMMV, most probably.