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: Progress report on git-blame Date: Sat, 25 Jan 2014 19:30:05 +0100 Message-ID: <87vbx7c3te.fsf@fencepost.gnu.org> References: <20140109140226.57D6C38085A@snark.thyrsus.com> <20140110155121.GA8178@thyrsus.com> <20140111205925.GC17111@thyrsus.com> <87y52mdoha.fsf@fencepost.gnu.org> <87fvoceuos.fsf_-_@fencepost.gnu.org> <83d2jgcy5z.fsf@gnu.org> <87vbx8cu8a.fsf@fencepost.gnu.org> <87eh3v7wiq.fsf@building.gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390674615 11365 80.91.229.3 (25 Jan 2014 18:30:15 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 25 Jan 2014 18:30:15 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 25 19:30:20 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 1W77zn-0006nb-TM for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 19:30:20 +0100 Original-Received: from localhost ([::1]:52141 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W77zn-0002AK-9b for ged-emacs-devel@m.gmane.org; Sat, 25 Jan 2014 13:30:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W77zf-00021u-EP for emacs-devel@gnu.org; Sat, 25 Jan 2014 13:30:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W77za-0005p6-OU for emacs-devel@gnu.org; Sat, 25 Jan 2014 13:30:11 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47916) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W77za-0005p2-ME for emacs-devel@gnu.org; Sat, 25 Jan 2014 13:30:06 -0500 Original-Received: from localhost ([127.0.0.1]:55090 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W77za-0000w9-4U; Sat, 25 Jan 2014 13:30:06 -0500 Original-Received: by lola (Postfix, from userid 1000) id AF987E0725; Sat, 25 Jan 2014 19:30:05 +0100 (CET) In-Reply-To: <87eh3v7wiq.fsf@building.gnus.org> (Lars Ingebrigtsen's message of "Sat, 25 Jan 2014 11:21:17 -0700") 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:169072 Archived-At: Lars Ingebrigtsen writes: > David Kastrup writes: > >> Apart from trying to bully up general git performance and from trying to >> get the unpacking to cache smarter, it would also be feasible to add a >> "fast track" interface to git blame --interactive where Emacs sends >> information about "currently viewed material corresponds to lines >> xxx...yyy in the file" to the running git process which is used for >> prioritizing the outstanding work. > > That sounds quite useful. My common bug fixing use case is that I find > a function (or a bit of a function) that I think has a bug, and then I > `C-x v g' to find out who "who wrote this crap anyway!!!" (it usually > turns out to be myself), and then I try to see whether any of the lines > are suspiciously new and may have introduced a new bug. > > So I'm usually just interested in a screenful of lines. If we could > have a version of `C-x v g' that only does "blame" for the current > region, for instance, that would certainly fit my use case. It's worth noting that you already _can_ ask "git blame" for just a region. However, implementing this into a general update strategy will mean that you'll usually have one git blame --incremental running for the big picture, and one-shot git-blame instances for producing the missing parts from the currently exposed area (probably sigstopping the "big" process while the small updates run). That means parallel work that will ultimately go wasted. It does have the advantage of working with the currently available binaries. A dynamically adjusted search seems nicer. -- David Kastrup