From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req. Date: Mon, 06 Jan 2014 19:07:02 +0100 Message-ID: <87iotxugqh.fsf@fencepost.gnu.org> References: <20140102095347.6834E381D0C@snark.thyrsus.com> <87fvp6bdd9.fsf_-_@ktab.red-bean.com> <8761q1ljny.fsf@gmail.com> <20140103175006.GE17261@thyrsus.com> <87ppo6u3mr.fsf@mid.deneb.enyo.de> <874n5i40th.fsf@mid.deneb.enyo.de> <87y52tupp3.fsf@fencepost.gnu.org> <8361pxt7lc.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389031645 8612 80.91.229.3 (6 Jan 2014 18:07:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 18:07:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 06 19:07:31 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 1W0EaH-0000CO-B9 for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 19:07:29 +0100 Original-Received: from localhost ([::1]:36645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0EaG-00022H-Re for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 13:07:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55458) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0EaD-00020H-RD for emacs-devel@gnu.org; Mon, 06 Jan 2014 13:07:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0EaA-0006D9-4B for emacs-devel@gnu.org; Mon, 06 Jan 2014 13:07:25 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39055) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0EaA-0006D5-10 for emacs-devel@gnu.org; Mon, 06 Jan 2014 13:07:22 -0500 Original-Received: from localhost ([127.0.0.1]:46231 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Ea9-0005ho-E3; Mon, 06 Jan 2014 13:07:21 -0500 Original-Received: by lola (Postfix, from userid 1000) id 3AA48E0891; Mon, 6 Jan 2014 19:07:02 +0100 (CET) In-Reply-To: <8361pxt7lc.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 06 Jan 2014 18:09:51 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:167490 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> Date: Mon, 06 Jan 2014 15:53:28 +0100 >> >> Richard Stallman writes: >> >> > I never consult changelog files if I have the full VCS history. >> > >> > I do. I use the ChangeLog files to see what changes affected a >> > certain function. >> >> I tend to use C-x v g for that (it maps to git blame). > > This can be annoyingly slow (and with git is slower than with bzr). > E.g., try xdisp.c: it takes git more than 4 minutes to display > anything in response to "C-x v g" (2 minutes if done from the shell). Oh wow. Impressive. Not my average experience, but certainly a sobering outlier. > Someone, I think it was you, once told me that the slow operation of > 'git blame' was a deliberate design decision of the git developers. Yes and no. The information is reconstructed rather than stored, but in general the information is reconstructed rather fast. git blame also has an incremental mode. For cases such like this, it might make sense trying to find a way to integrate this into the operation of C-x v g though I have to admit that I am somewhat at a loss regarding how to do this in a pleasant way. > So it doesn't sound like this is supposed to be the first tool to be > used for such jobs. FWIW, I use that only after I already have some > idea about what I'm looking for and in which time period. In general, it works pretty well for me. I have to admit that xdisp.c is convincingly bad in that regard. -- David Kastrup