From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Sergey Organov Newsgroups: gmane.emacs.devel Subject: Re: vc-dir operation is very slow on large git repositories in Emacs 26.1 Date: Tue, 26 Jun 2018 18:14:40 +0300 Message-ID: <87bmbxbmvz.fsf@javad.com> References: <83k1qtsbgi.fsf@gnu.org> <30712254-6225-c6a8-1457-698c64e37739@yandex.ru> <83zhzltyii.fsf@gnu.org> <5218794b-b9ef-3c0d-d3c1-bf40c42e64b2@yandex.ru> <83r2kxtk9w.fsf@gnu.org> <5095ed13-d4a8-1699-26f9-746afaee0248@yandex.ru> <83in66sxig.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1530026013 27311 195.159.176.226 (26 Jun 2018 15:13:33 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Jun 2018 15:13:33 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) Cc: alexharsanyi@gmail.com, tom@tromey.com, emacs-devel@gnu.org, Dmitry Gutov To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 26 17:13:28 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fXpeo-0006yN-UB for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2018 17:13:27 +0200 Original-Received: from localhost ([::1]:53288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXpgw-00072G-8q for ged-emacs-devel@m.gmane.org; Tue, 26 Jun 2018 11:15:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53658) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fXpg8-0006Vg-SY for emacs-devel@gnu.org; Tue, 26 Jun 2018 11:14:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fXpg7-0001F1-OZ for emacs-devel@gnu.org; Tue, 26 Jun 2018 11:14:48 -0400 Original-Received: from mail.javad.com ([54.86.164.124]:48110) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fXpg4-0001E4-1P; Tue, 26 Jun 2018 11:14:44 -0400 Original-Received: from osv (unknown [89.175.180.246]) by mail.javad.com (Postfix) with ESMTPSA id D05823FF81; Tue, 26 Jun 2018 15:14:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=javad.com; s=default; t=1530026082; bh=Vw7t6q5HubUkSdL5j4bukOQa1GcxKpugucXfiGop124=; l=966; h=Received:From:To:Subject; b=KuHqYpHaEuaudvJTRwmdW2dSDRsNyKC9T09qjxkm5Eh/sBmnLKiFXkEqy2SE5h8JV PAF6v6i0HY44Eb2Q+y8LJV6kIjsiQg2+Joa87hnbP2sYY3rZABBJpYhaLXrWIHFR3Q fRcEk9JMkU9b0t8HwspBhH0oPboDCqyumFb2yX7I= Authentication-Results: ip-172-31-2-110; spf=pass (sender IP is 89.175.180.246) smtp.mailfrom=osv@javad.com smtp.helo=osv Received-SPF: pass (ip-172-31-2-110: connection is authenticated) Original-Received: from osv by osv with local (Exim 4.84_2) (envelope-from ) id 1fXpg0-0003B8-2H; Tue, 26 Jun 2018 18:14:40 +0300 In-Reply-To: <83in66sxig.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 25 Jun 2018 18:20:55 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 54.86.164.124 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:226741 Archived-At: Eli Zaretskii writes: >> Cc: alexharsanyi@gmail.com, tom@tromey.com, emacs-devel@gnu.org >> From: Dmitry Gutov >> Date: Mon, 25 Jun 2018 15:55:38 +0300 >> >> It's used to obtain the list of conflicted files. Which is the new >> feature added in the bug report I've referenced. >> >> I'm not quite sure why we have to fetch the list of all files in the >> repository to do that. >> >> It seems like the approach was simply adapted from the >> ls-files-up-to-date stage, but that one is only called for a list of >> individual files, not for the status of a whole directory (e.g. whole >> repository). > > Maybe some Git expert could suggest a more economical way of doing the > same? (I'm not that expert.) Not exactly an expert, but googling suggests 'git ls-files -u' as the answer. Please be aware that the output will have 3 entries for every conflicting file: merge base, theirs, and ours. -- Sergey