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: Apologia for bzr Date: Fri, 03 Jan 2014 12:08:51 +0200 Message-ID: <83bnztxtqk.fsf@gnu.org> References: <20140102211452.GA28685@c3po> <83d2k9xx1f.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1388743757 30037 80.91.229.3 (3 Jan 2014 10:09:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jan 2014 10:09:17 +0000 (UTC) Cc: esr@thyrsus.com, kfogel@red-bean.com, toby-dated-1389906911.cc0ede@dr-qubit.org, emacs-devel@gnu.org To: Yuri Khan Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 03 11:09:22 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 1Vz1gw-0006Qe-DE for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2014 11:09:22 +0100 Original-Received: from localhost ([::1]:48951 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz1gv-0001E4-Q1 for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2014 05:09:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz1go-0001Dh-UX for emacs-devel@gnu.org; Fri, 03 Jan 2014 05:09:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vz1gj-0003Ge-5M for emacs-devel@gnu.org; Fri, 03 Jan 2014 05:09:14 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:45510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vz1gi-0003Ga-TP for emacs-devel@gnu.org; Fri, 03 Jan 2014 05:09:09 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0MYT00200LF1M600@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Fri, 03 Jan 2014 12:08:50 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MYT002C6LIQJW30@a-mtaout20.012.net.il>; Fri, 03 Jan 2014 12:08:50 +0200 (IST) 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.166 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:167138 Archived-At: > Date: Fri, 3 Jan 2014 16:21:26 +0700 > From: Yuri Khan > Cc: Toby Cubitt , > Eric Raymond , kfogel@red-bean.com, > Emacs developers > > On Fri, Jan 3, 2014 at 3:57 PM, Eli Zaretskii wrote: > > > > If you don't already know what is "staging", you will never understand > > that this is one of the most important and useful options. Also, > > "haven't told Git about new files" fails to mention "git add". Once > > I've managed to grasp all that, I've made an alias for "commit -a", > > because that's what I almost always want. (And why isn't that the > > default, dammit?) > > Because staging is a key concept in git and it enables a whole lot of > useful workflows. I know that. Don't take my questions as indications that I'm unfamiliar with basic git terminology (I was once, but no more). > E.g. you can work all day and half the next day on a > feature, making small formatting changes and fix coding style > violations on your way as you spot them, then fire up a commit tool > and make three commits, one for trivial formatting changes, another > for coding style fixes, and a third one with the feature you actually > worked on. I was talking about the defaults. For the defaults, the important question is what would J. R. Hacker want in most of his commits. It seems to me that occasional contributors to projects (as opposed to their core developers) will seldom if ever get to the complicated workflows you describe. It's definitely true for me in a couple of projects in which I'm involved (not Emacs, obviously). > Without staging, you would have to look at the diff, back up and > revert some changes so that the working directory looks the way you > want for one commit, then the other, then the next one. Or you would > hold off fixing small things until you have committed the feature, and > risk forgetting to do them. Well, let's begin by agreeing that what you described is just bad habit: you should commit very frequently, and so seldom if ever get to the point where you have hacked for a day and a half without a single commit.