From patchwork Sun Aug 18 18:27:57 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?SZEDER_G=C3=A1bor?= X-Patchwork-Id: 11099841 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1787618A6 for ; Sun, 18 Aug 2019 18:28:15 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 07D9322B39 for ; Sun, 18 Aug 2019 18:28:15 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F085E27DCD; Sun, 18 Aug 2019 18:28:14 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A14CD28399 for ; Sun, 18 Aug 2019 18:28:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726988AbfHRS2N (ORCPT ); Sun, 18 Aug 2019 14:28:13 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:39879 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726927AbfHRS2N (ORCPT ); Sun, 18 Aug 2019 14:28:13 -0400 Received: by mail-wr1-f67.google.com with SMTP id t16so6384407wra.6 for ; Sun, 18 Aug 2019 11:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ahcbSRj/v9mEepZ2JG2IjEq24r+5A4zJGoDXz3QkxTM=; b=gcUZIyBN41reC9yFH9RYnE5rIH2Urxfp5gQ5zaMZ2v5yb+bWMmOcjzGh0o9ZWf9Pja A72WcGeX9k7HMUGhVEbcfpPaBB8tSMLxhtte0pKEoBDofLYBQ5Bbi55YuKVMMnkXtAGU 1vKgElpNVTSsmkykNbMXvRg/hsoUlWS1sAq5Y511drt5gmiwNe292i0F+9M1Fz6pOZ9d Web9qOA+ibXhLLkgE/QSXFAD854iulZq0o9CkHwKAj7g0vmoeb2XgYbmYTTHkGQoVJrE Z00VujU32p2EYUpJCLbljfeQsS85EaT6Ho2xo3IRUD7BPs9FWva8UQktG5uH6lTo/MPn q4HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ahcbSRj/v9mEepZ2JG2IjEq24r+5A4zJGoDXz3QkxTM=; b=AObAuwm/ltvEgzrT3i1VVDc16ylUOh84tHXInGeML50pQH24I11G3uYWe2FQ70jgO6 j4Ys79Ij4F0u1NHM2igJHZhCiqRuTWoG3tU9D/Fy26wkU3EiqhGOxU6K5m3AuuBqRAU2 ghk31FbsenL5TgT0biapRt6fU/7Thwcy+KDMToKHlPUFsLWWOh1LWBEm6c+DwS8usgmh WuogbhBzJEQdvoiToYCLbC3ojSKa6XDUx50/cA+2eciztSCPrQrzA4hy2WoRcu48f3T/ uCxIAOo10sMcWkeZJg6CQGClrwp8wFQF5FBzkLN1yytJgc39amp6F2IKE7Fqsj/pN56b IAiQ== X-Gm-Message-State: APjAAAVw4tenCPpFx/fqQqTutaGR5iFdxK+eGubmS6yeqbmdcLce12Ll hQst9ZEqDYsUs7tOVdNnPXBJrT6v X-Google-Smtp-Source: APXvYqxKpYobt3/D/qFLDd7QMdZLK3yOyYuTbOFVfjqeZTcZdKrDqgbSHeF/+ecCxhdl7lJ8Yjc3FQ== X-Received: by 2002:a05:6000:104c:: with SMTP id c12mr19772117wrx.328.1566152891316; Sun, 18 Aug 2019 11:28:11 -0700 (PDT) Received: from localhost.localdomain (x4db53457.dyn.telefonica.de. [77.181.52.87]) by smtp.gmail.com with ESMTPSA id c201sm24112584wmd.33.2019.08.18.11.28.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Aug 2019 11:28:10 -0700 (PDT) From: =?utf-8?q?SZEDER_G=C3=A1bor?= To: git@vger.kernel.org Cc: Junio C Hamano , Thomas Rast , Derrick Stolee , =?utf-8?q?SZEDER_G=C3=A1bor?= Subject: [RFC PATCH 1/5] completion: offer '--(no-)patch' among 'git log' options Date: Sun, 18 Aug 2019 20:27:57 +0200 Message-Id: <20190818182801.7580-2-szeder.dev@gmail.com> X-Mailer: git-send-email 2.23.0.349.g73f10e387d In-Reply-To: <20190818182801.7580-1-szeder.dev@gmail.com> References: <20190818182801.7580-1-szeder.dev@gmail.com> MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: SZEDER Gábor --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index e087c4bf00..57f984340e 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -1804,6 +1804,7 @@ _git_log () $merge $__git_diff_common_options --pickaxe-all --pickaxe-regex + --patch --no-patch " return ;; From patchwork Sun Aug 18 18:27:58 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?SZEDER_G=C3=A1bor?= X-Patchwork-Id: 11099843 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4C88E13B1 for ; Sun, 18 Aug 2019 18:28:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3D0C622B39 for ; Sun, 18 Aug 2019 18:28:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 309A52811E; Sun, 18 Aug 2019 18:28:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DB9AC22B39 for ; Sun, 18 Aug 2019 18:28:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727059AbfHRS2P (ORCPT ); Sun, 18 Aug 2019 14:28:15 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:38709 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726927AbfHRS2P (ORCPT ); Sun, 18 Aug 2019 14:28:15 -0400 Received: by mail-wm1-f66.google.com with SMTP id m125so1097061wmm.3 for ; Sun, 18 Aug 2019 11:28:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=rOuvYwCPrEvpM1MdzqfsZnAM2NuXgVbgQdSPCyG2SKc=; b=rN7EgwjDiGx5Z/xfdwniwzVJfv5iLdtSt+Wq6XHofwLZYZRMbPWQKgnLzqdYDKPsKe Tyov6ROGX9mYobAhSlzPhgQ9gUBUi2c2TrT0zCEYebkRzrSKE7rC37qO4aXM9m9uV30Q ISX4Pf6Ioy8YE9PgH1Ast6R8w2/NChsA5ZCdbfu14mC6/keIIP4luE0VwCnbJ1ve/Or5 AivFzKZenE6MWN5ZlgIRa5qJALG2LP0SVTJ5z/UtDZNXH03Uu1FqimIhNJa22RWqClHE 93ygKKvI+d1GRq+K21WlqGTrX4r3czXT5vVcnxDcAPqEWir8pNvuEXR0CB1pmn/SzTA8 FX5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=rOuvYwCPrEvpM1MdzqfsZnAM2NuXgVbgQdSPCyG2SKc=; b=jKwHnTrXkZocw+xUftuvEuSyhjRkLhDB5asQFSfJKt6sXQmPxQWMOPCUON+abCTOis GD73DgsnLXuh5YzIwy/RH/6F8VnUQBQ9WFm6FwFJwwz6RjoVd+qSPumohCPE1BVmlPdf 1Z1icNW+JLJYVVGARQiu/mePU7LoRu3lpcSfFARGKugtmRWBkFabhyRq+bBZWOBMNF/S fXrOeQVtWXy92oJHCW7JPqQ+e0Q3osPRHe19iok2qT+U+e8dJkxQBKfZFmlaPEMShxLo Vz4mL65zoUKL4VjWG2+dvsNE8ImDRLGoVsCghZfZu8hT5/Ok5W9/Nb0h67uoKw173BEX 6q4w== X-Gm-Message-State: APjAAAVvjg7GGgjul8Lod4K5l1qbSosQVhTiRzojwV7iCygK/Rm4YWkM 8/1+EtU5tJu6AYbxhSoqrBlwtZ36 X-Google-Smtp-Source: APXvYqxo/t4zhzh5WKViAgJ67N8rDuq55/yXQtLIpa9vS2UZTDBpr9zuhFpLCnEZtYs/cvHOyj1YwA== X-Received: by 2002:a1c:6782:: with SMTP id b124mr17642142wmc.143.1566152893183; Sun, 18 Aug 2019 11:28:13 -0700 (PDT) Received: from localhost.localdomain (x4db53457.dyn.telefonica.de. [77.181.52.87]) by smtp.gmail.com with ESMTPSA id c201sm24112584wmd.33.2019.08.18.11.28.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Aug 2019 11:28:12 -0700 (PDT) From: =?utf-8?q?SZEDER_G=C3=A1bor?= To: git@vger.kernel.org Cc: Junio C Hamano , Thomas Rast , Derrick Stolee , =?utf-8?q?SZEDER_G=C3=A1bor?= Subject: [RFC PATCH 2/5] line-log: remove unused fields from 'struct line_log_data' Date: Sun, 18 Aug 2019 20:27:58 +0200 Message-Id: <20190818182801.7580-3-szeder.dev@gmail.com> X-Mailer: git-send-email 2.23.0.349.g73f10e387d In-Reply-To: <20190818182801.7580-1-szeder.dev@gmail.com> References: <20190818182801.7580-1-szeder.dev@gmail.com> MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Remove the unused fields 'status', 'arg_alloc', 'arg_nr' and 'args' from 'struct line_log_data'. They were already part of the struct when it was introduced in commit 12da1d1f6 (Implement line-history search (git log -L), 2013-03-28), but as far as I can tell none of them have ever been actually used. Signed-off-by: SZEDER Gábor --- line-log.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/line-log.h b/line-log.h index 8ee7a2bd4a..882c5055bb 100644 --- a/line-log.h +++ b/line-log.h @@ -46,10 +46,7 @@ void sort_and_merge_range_set(struct range_set *); struct line_log_data { struct line_log_data *next; char *path; - char status; struct range_set ranges; - int arg_alloc, arg_nr; - const char **args; struct diff_filepair *pair; struct diff_ranges diff; }; From patchwork Sun Aug 18 18:27:59 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?SZEDER_G=C3=A1bor?= X-Patchwork-Id: 11099845 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1685E13B1 for ; Sun, 18 Aug 2019 18:28:19 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 06DA822B39 for ; Sun, 18 Aug 2019 18:28:19 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EF29A2811E; Sun, 18 Aug 2019 18:28:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7F8C422B39 for ; Sun, 18 Aug 2019 18:28:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727075AbfHRS2R (ORCPT ); Sun, 18 Aug 2019 14:28:17 -0400 Received: from mail-wm1-f67.google.com ([209.85.128.67]:40075 "EHLO mail-wm1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726005AbfHRS2Q (ORCPT ); Sun, 18 Aug 2019 14:28:16 -0400 Received: by mail-wm1-f67.google.com with SMTP id v19so1098031wmj.5 for ; Sun, 18 Aug 2019 11:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=SNaV1OAXYuPmrUC9mHsktPzFXluKOnASERv2LDjAxUw=; b=el8M6P8X/efTurz9J7kEPO71msh6iIeQCgbJyILfxic1NUejFw9qMSZmZW0g+W5aPs UoCUNPw3H0jenQGilFQncx90vxI6ASO6n3NVAGL4gDfZ/2CibkN6QZ4zlcvqXUcwlYZ0 W+7fKZV7cT6tw25S4017wkhAufBmhLWLOQDvfqBEyACOy7FqZGXz/qDp1Ua5iillzLLZ u5eQ6+Fbfj6sZeQDkBZzxw84AW1B3skGrdSa/e88iMPYnyodhmR2ggYDKB8ChVcyba5u k4AoCLF941ZVdsuP4z4bQKRNgutdG1w+bbKsjXS4aAY6m5FtwnmdnS9ZrQfSvEhxIOjq KFNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=SNaV1OAXYuPmrUC9mHsktPzFXluKOnASERv2LDjAxUw=; b=qt4fBaauq9duwtFi/+FPDX4+ggA/sE3juJBVn0C49fValYFMX4TktjY33wN4WwZHc3 yVs7iAl5Ahu3qhOE+tOD8HT1PLYVgcUD2CqFxSzlKXotAk2BoLMttuA4B+aFmEalsQEo gXoIiMiCJ0BF4TAnHL+hJrXsfhMs01xI3Z3kp9SoUid2N2tmsrnUjANQUjC40W/odnbR lrxh8xysBNQh20D1Y7QUnp4A06XnUeGGdN1YNOcd1V+kFpXcMBv04RaHPTsdhYQTE85A vowscZdkTiVuLce3qGTMPWdz0W8vxjuRe/xo9HqbFUnoQQUlcQaMNeze8Y5wLsnBk+AV R+1g== X-Gm-Message-State: APjAAAXhUtFBz7Y4YDwpm9H710pZduYoNG1erKarfqwrd+LnITO4lL1O ZpmACmDCNvE3XCuXqmHXPBtMs1XX X-Google-Smtp-Source: APXvYqyeXHdwzvdoChMofsfMwviUBZ23wWC7854A07Hmm+Ow2cxzvtFJcg0UQ+45pLhfzFU3N3aEXg== X-Received: by 2002:a05:600c:352:: with SMTP id u18mr16723249wmd.141.1566152894630; Sun, 18 Aug 2019 11:28:14 -0700 (PDT) Received: from localhost.localdomain (x4db53457.dyn.telefonica.de. [77.181.52.87]) by smtp.gmail.com with ESMTPSA id c201sm24112584wmd.33.2019.08.18.11.28.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Aug 2019 11:28:13 -0700 (PDT) From: =?utf-8?q?SZEDER_G=C3=A1bor?= To: git@vger.kernel.org Cc: Junio C Hamano , Thomas Rast , Derrick Stolee , =?utf-8?q?SZEDER_G=C3=A1bor?= Subject: [RFC PATCH 3/5] t4211-line-log: add tests for parent oids Date: Sun, 18 Aug 2019 20:27:59 +0200 Message-Id: <20190818182801.7580-4-szeder.dev@gmail.com> X-Mailer: git-send-email 2.23.0.349.g73f10e387d In-Reply-To: <20190818182801.7580-1-szeder.dev@gmail.com> References: <20190818182801.7580-1-szeder.dev@gmail.com> MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP None of the tests in 't4211-line-log.sh' really check which parent object IDs are shown in the output, either implicitly as part of "Merge: ..." lines [1] or explicitly via the '%p' or '%P' format specifiers in a custom pretty format. Add two tests to 't4211-line-log.sh' to check which parent object IDs are shown, one without and one with explicitly requested parent rewriting, IOW without and with the '--parents' option. The test without '--parents' is marked as failing, because without that option parent rewriting should not be performed, and thus the parent object ID should be that of the immediate parent, just like in case of a pathspec-limited history traversal without parent rewriting. The current line-level log implementation, however, performs parent rewriting unconditionally and without a possibility to turn it off, and, consequently, it shows the object ID of the most recent ancestor that modified the given line range. In both of these new tests we only really care about the object IDs of the listed commits and their parents, but not the diffs of the line ranges; the diffs have already been thoroughly checked in the previous tests. [1] While one of the tests ('-M -L ':f:b.c' parallel-change') does list a merge commit, both of its parents happen to modify the given line range and are listed as well, so the implications of parent rewriting remained hidden and untested. Signed-off-by: SZEDER Gábor --- t/t4211-line-log.sh | 68 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh index 1db7bd0f59..c378a453de 100755 --- a/t/t4211-line-log.sh +++ b/t/t4211-line-log.sh @@ -132,4 +132,72 @@ test_expect_success '--raw is forbidden' ' test_must_fail git log -L1,24:b.c --raw ' +# Create the following linear history, where each commit does what its +# subject line promises: +# +# * 66c6410 Modify func2() in file.c +# * 50834e5 Modify other-file +# * fe5851c Modify func1() in file.c +# * 8c7c7dd Add other-file +# * d5f4417 Add func1() and func2() in file.c +test_expect_success 'setup for checking line-log and parent oids' ' + git checkout --orphan parent-oids && + git reset --hard && + + cat >file.c <<-\EOF && + int func1() + { + return F1; + } + + int func2() + { + return F2; + } + EOF + git add file.c && + test_tick && + git commit -m "Add func1() and func2() in file.c" && + + echo 1 >other-file && + git add other-file && + git commit -m "Add other-file" && + + sed -e "s/F1/F1 + 1/" file.c >tmp && + mv tmp file.c && + git commit -a -m "Modify func1() in file.c" && + + echo 2 >other-file && + git commit -a -m "Modify other-file" && + + sed -e "s/F2/F2 + 2/" file.c >tmp && + mv tmp file.c && + git commit -a -m "Modify func2() in file.c" && + + head_oid=$(git rev-parse --short HEAD) && + prev_oid=$(git rev-parse --short HEAD^) && + root_oid=$(git rev-parse --short HEAD~4) +' + +# Parent oid should be from immediate parent. +test_expect_failure 'parent oids without parent rewriting' ' + cat >expect <<-EOF && + $head_oid $prev_oid Modify func2() in file.c + $root_oid Add func1() and func2() in file.c + EOF + git log --format="%h %p %s" --no-patch -L:func2:file.c >actual && + test_cmp expect actual +' + +# Parent oid should be from the most recent ancestor touching func2(), +# i.e. in this case from the root commit. +test_expect_success 'parent oids with parent rewriting' ' + cat >expect <<-EOF && + $head_oid $root_oid Modify func2() in file.c + $root_oid Add func1() and func2() in file.c + EOF + git log --format="%h %p %s" --no-patch -L:func2:file.c --parents >actual && + test_cmp expect actual +' + test_done From patchwork Sun Aug 18 18:28:00 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?SZEDER_G=C3=A1bor?= X-Patchwork-Id: 11099847 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 55386112C for ; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 44D8D22B39 for ; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 393262811E; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5E36122B39 for ; Sun, 18 Aug 2019 18:28:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727093AbfHRS2T (ORCPT ); Sun, 18 Aug 2019 14:28:19 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:34344 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726927AbfHRS2T (ORCPT ); Sun, 18 Aug 2019 14:28:19 -0400 Received: by mail-wm1-f66.google.com with SMTP id e8so1140699wme.1 for ; Sun, 18 Aug 2019 11:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=BqBm2c0SHbd5AcJKFCJ0VSpr7Oo6uY+aBiNzs5Iftv0=; b=s4ApkALmd5rjYDEYp3BdOp0YS178k9eW0rSrtoCgPTIvAziuwklw9y7FQSiT74qd7T KWKLqxTPLK79GTGpwWzPqyKwYhouN9JTjPbEt4xmFWnJKTjCbUMk6z62Y7oj4APxH5eI MV3NDbvt/ob88YI/JC8a9riHY44qWUmw6Xfm1Re9ah23AkzkU9lzbF/EPikofeGGkWzO 9phPzl4dNjYil3yrQcIKID98VOWmcKRtneZpd1JMsc7QfmeWgPTySsYR2GVyVvnEdogD T6KrzoE1/A2jv+WB3Wu69WhHAPulu7LGLJ7G68j5C67qj+RxC96t1AA4iz6N4fxNWxq9 T6Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=BqBm2c0SHbd5AcJKFCJ0VSpr7Oo6uY+aBiNzs5Iftv0=; b=A93wfD2g8iSvfIX8hsv5AOuCsY63PWHDtdKRdl6DOQBqhbYq1kEYuznu2oWz6iO2NE Y2Pvhpo5y8Zzn13o2okwOzB5EI15DQYP87jd2cp4K+ACVThTCa6sx4gtPBP4pT20RLU1 JHGY2raLdx8OLGG/j1tWvwGkbZHuPeeGcu43sBOVZavIWkAW8fUYLM8QZfy1e1KaF18+ U1YsRQraoN1IWC2txlbOIbQqZpCa2JbP6AFOe0Z52gH9EDrv47ARZf5jGQ1F5ggdLr/y JT2vaUDQUsyPwHOBVcTY4a2BJb7maistm4q5zAh1WQR5kznZ3cRjREmtWyp2LSnJbCg5 5RJw== X-Gm-Message-State: APjAAAWkGJ50+OJ/rqZBc7qqEKp+6olqfUeHy0RnjJPUPmXUPy6sP4Rd n3vGFrZLVh6jyMurPWBqD4kXuKZV X-Google-Smtp-Source: APXvYqww3Mv4a/gYlqppXOsRXaIxZWliMmvQlxTSsAOBs1NeM1sRK8EfgeJhriE7HoyORx+SxXDzlQ== X-Received: by 2002:a1c:c188:: with SMTP id r130mr16080982wmf.73.1566152895880; Sun, 18 Aug 2019 11:28:15 -0700 (PDT) Received: from localhost.localdomain (x4db53457.dyn.telefonica.de. [77.181.52.87]) by smtp.gmail.com with ESMTPSA id c201sm24112584wmd.33.2019.08.18.11.28.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Aug 2019 11:28:15 -0700 (PDT) From: =?utf-8?q?SZEDER_G=C3=A1bor?= To: git@vger.kernel.org Cc: Junio C Hamano , Thomas Rast , Derrick Stolee , =?utf-8?q?SZEDER_G=C3=A1bor?= Subject: [RFC PATCH 4/5] line-log: more responsive, incremental 'git log -L' Date: Sun, 18 Aug 2019 20:28:00 +0200 Message-Id: <20190818182801.7580-5-szeder.dev@gmail.com> X-Mailer: git-send-email 2.23.0.349.g73f10e387d In-Reply-To: <20190818182801.7580-1-szeder.dev@gmail.com> References: <20190818182801.7580-1-szeder.dev@gmail.com> MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The current line-level log implementation performs a preprocessing step in prepare_revision_walk(), during which the line_log_filter() function filters and rewrites history to keep only commits modifying the given line range. This preprocessing affects both responsiveness and correctness: - Git doesn't produce any output during this preprocessing step. Checking whether a commit modified the given line range is somewhat expensive, so depending on the size of the given revision range this preprocessing can result in a significant delay before the first commit is shown. - Limiting the number of displayed commits (e.g. 'git log -3 -L...') doesn't limit the amount of work during preprocessing, because that limit is applied during history traversal. Alas, by that point this expensive preprocessing step has already churned through the whole revision range to find all commits modifying the revision range, even though only a few of them need to be shown. - It rewrites parents, with no way to turn it off. Without the user explicitly requesting parent rewriting any parent object ID shown should be that of the immediate parent, just like in case of a pathspec-limited history traversal without parent rewriting. However, after that preprocessing step rewrote history, the subsequent "regular" history traversal (i.e. get_revision() in a loop) only sees commits modifying the given line range. Consequently, it can only show the object ID of the last ancestor that modified the given line range (which might happen to be the immediate parent, but many-many times it isn't). This patch addresses both the correctness and, at least for the common case, the responsiveness issues by integrating line-level log filtering into the regular revision walking machinery: - Make process_ranges_arbitrary_commit(), the static function in 'line-log.c' deciding whether a commit modifies the given line range, public by removing the static keyword and adding the 'line_log_' prefix, so it can be called from other parts of the revision walking machinery. - If the user didn't explicitly ask for parent rewriting (which, I believe, is the most common case): - Call this now-public function during regular history traversal, namely from get_commit_action() to ignore any commits not modifying the given line range. Note that while this check is relatively expensive, it must be performed before other, much cheaper conditions, because the tracked line range must be adjusted even when the commit will end up being ignored by other conditions. - Skip the line_log_filter() call, i.e. the expensive preprocessing step, in prepare_revision_walk(), because, thanks to the above points, the revision walking machinery is now able to filter out commits not modifying the given line range while traversing history. This way the regular history traversal sees the unmodified history, and is therefore able to print the object ids of the immediate parents of the listed commits. The eliminated preprocessing step can greatly reduce the delay before the first commit is shown, see the numbers below. - However, if the user did explicitly ask for parent rewriting via '--parents' or a similar option, then stick with the current implementation for now, i.e. perform that expensive filtering and history rewriting in the preprocessing step just like we did before, leaving the initial delay as long as it was. I tried to integrate line-level log filtering with parent rewriting into the regular history traversal, but, unfortunately, several subtleties resisted... :) Maybe someday we'll figure out how to do that, but until then at least the simple and common (i.e. without parent rewriting) 'git log -L:func:file' commands can benefit from the reduced delay. This change makes the failing 'parent oids without parent rewriting' test in 't4211-line-log.sh' succeed. The reduced delay is most noticable when there's a commit modifying the line range near the tip of a large-ish revision range: # no parent rewriting requested, no commit-graph present $ time git --no-pager log -L:read_alternate_refs:sha1-file.c -1 v2.23.0 Before: real 0m9.570s user 0m9.494s sys 0m0.076s After: real 0m0.718s user 0m0.674s sys 0m0.044s A significant part of the remaining delay is spent reading and parsing commit objects in limit_list(). With the help of the commit-graph we can eliminate most of that reading and parsing overhead, so here are the timing results of the same command as above, but this time using the commit-graph: Before: real 0m8.874s user 0m8.816s sys 0m0.057s After: real 0m0.107s user 0m0.091s sys 0m0.013s The next patch will further reduce the remaining delay. To be clear: this patch doesn't actually optimize the line-level log, but merely moves most of the work from the preprocessing step to the history travelsal, so the commits modifying the line range can be shown as soon as they are processed, and the traversal can be terminated as soon as the given number of commits are shown. Consequently, listing the full history of a line range, potentially all the way to the root commit, will take the same time as before (but at least the user might start reading the output earlier). Furthermore, if the most recent commit modifying the line range is far away from the starting revision, then that initial delay will still be significant. Signed-off-by: SZEDER Gábor --- Notes: Regarding that "most common case": I know, I know, one should not extrapolate only from his own usage patterns... But FWIW, I've been using various versions of this patch for over two years now, and never missed the rewritten parents. And just pulled a couple of years worth of ~/.bash_history files from backups, and there was not a single occasion where I used line-level log with parent rewriting (apart from testing these changes). line-log.c | 4 ++-- line-log.h | 2 ++ revision.c | 27 ++++++++++++++++++++++++++- t/t4211-line-log.sh | 2 +- 4 files changed, 31 insertions(+), 4 deletions(-) diff --git a/line-log.c b/line-log.c index 3aff1849e7..772ab57d52 100644 --- a/line-log.c +++ b/line-log.c @@ -1194,7 +1194,7 @@ static int process_ranges_merge_commit(struct rev_info *rev, struct commit *comm /* NEEDSWORK leaking like a sieve */ } -static int process_ranges_arbitrary_commit(struct rev_info *rev, struct commit *commit) +int line_log_process_ranges_arbitrary_commit(struct rev_info *rev, struct commit *commit) { struct line_log_data *range = lookup_line_range(rev, commit); int changed = 0; @@ -1237,7 +1237,7 @@ int line_log_filter(struct rev_info *rev) while (list) { struct commit_list *to_free = NULL; commit = list->item; - if (process_ranges_arbitrary_commit(rev, commit)) { + if (line_log_process_ranges_arbitrary_commit(rev, commit)) { *pp = list; pp = &list->next; } else diff --git a/line-log.h b/line-log.h index 882c5055bb..82ae8d98a4 100644 --- a/line-log.h +++ b/line-log.h @@ -54,6 +54,8 @@ struct line_log_data { void line_log_init(struct rev_info *rev, const char *prefix, struct string_list *args); int line_log_filter(struct rev_info *rev); +int line_log_process_ranges_arbitrary_commit(struct rev_info *rev, + struct commit *commit); int line_log_print(struct rev_info *rev, struct commit *commit); diff --git a/revision.c b/revision.c index 07412297f0..6bdfcb38cd 100644 --- a/revision.c +++ b/revision.c @@ -36,6 +36,8 @@ static const char *term_good; implement_shared_commit_slab(revision_sources, char *); +static inline int want_ancestry(const struct rev_info *revs); + void show_object_with_name(FILE *out, struct object *obj, const char *name) { const char *p; @@ -3359,7 +3361,14 @@ int prepare_revision_walk(struct rev_info *revs) sort_in_topological_order(&revs->commits, revs->sort_order); } else if (revs->topo_order) init_topo_walk(revs); - if (revs->line_level_traverse) + if (revs->line_level_traverse && want_ancestry(revs)) + /* + * At the moment we can only do line-level log with parent + * rewriting by performing this expensive pre-filtering step. + * If parent rewriting is not requested, then we rather + * perform the line-level log filtering during the regular + * history traversal. + */ line_log_filter(revs); if (revs->simplify_merges) simplify_merges(revs); @@ -3569,6 +3578,22 @@ enum commit_action get_commit_action(struct rev_info *revs, struct commit *commi return commit_ignore; if (commit->object.flags & UNINTERESTING) return commit_ignore; + if (revs->line_level_traverse && !want_ancestry(revs)) { + /* + * In case of line-level log with parent rewriting + * prepare_revision_walk() already took care of all line-level + * log filtering, and there is nothing left to do here. + * + * If parent rewriting was not requested, then this is the + * place to perform the line-level log filtering. Notably, + * this check, though expensive, must come before the other, + * cheaper filtering conditions, because the tracked line + * ranges must be adjusted even when the commit will end up + * being ignored based on other conditions. + */ + if (!line_log_process_ranges_arbitrary_commit(revs, commit)) + return commit_ignore; + } if (revs->min_age != -1 && comparison_date(revs, commit) > revs->min_age) return commit_ignore; diff --git a/t/t4211-line-log.sh b/t/t4211-line-log.sh index c378a453de..8096208abb 100755 --- a/t/t4211-line-log.sh +++ b/t/t4211-line-log.sh @@ -180,7 +180,7 @@ test_expect_success 'setup for checking line-log and parent oids' ' ' # Parent oid should be from immediate parent. -test_expect_failure 'parent oids without parent rewriting' ' +test_expect_success 'parent oids without parent rewriting' ' cat >expect <<-EOF && $head_oid $prev_oid Modify func2() in file.c $root_oid Add func1() and func2() in file.c From patchwork Sun Aug 18 18:28:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?SZEDER_G=C3=A1bor?= X-Patchwork-Id: 11099849 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id E45F118A6 for ; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D525922B39 for ; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C9AD927DCD; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 51F9928399 for ; Sun, 18 Aug 2019 18:28:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727095AbfHRS2U (ORCPT ); Sun, 18 Aug 2019 14:28:20 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:35013 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726005AbfHRS2T (ORCPT ); Sun, 18 Aug 2019 14:28:19 -0400 Received: by mail-wr1-f66.google.com with SMTP id k2so6389977wrq.2 for ; Sun, 18 Aug 2019 11:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=PO9BYIrfXh56jG2MQnZKLDJN52D2cV0+O/dPenP9Jd8=; b=VtOR5JCzUgUBWOjrxM+4/WYrZBmqB/43xaJOYwppyuGHlxcSyiWt9fjxqEU2rBhVtR ln4g4ELAmt1vECN+QhGA/jU2FT/ZdzvCNJeSZ7q2iSB9RNuAKG/CU9d/23ebaVvJNKY/ NwhATOCZVi4xJGHQYGI5NihAC+msFliAuMsizzYthB9TpSuDdo3IzWHEEzr1GsYHLNmD zCCtat8Kz18vRT7cotGlsUtFZVMEv3PuiMK5fUHLw49B5bJLH6IxPz4YNSKRV+R9GINT 0uXM21hiVO9e45n3KUQTdFaaYQj0vCekgzjdefWmBBdNxyk9/cZPS5zv5YKZ547Bh96a AThQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=PO9BYIrfXh56jG2MQnZKLDJN52D2cV0+O/dPenP9Jd8=; b=Bfv0Rtd7C+rCecHlQHnGW9urbL1Y9SSdDyES+2DqZtKzfTHlfocGS6WSkDizpI0Smb JyC4zG5bDLcQc/ZSWX/yyjUcGSKfJo1FsMpQiwC4rEGQXdp6PzVTn4mI3goOqe/StNZF r/J3vr63YIcmv0RGq+0S2L4pjMo4VdqfFLuNy16S7UCo48H6ptF5eYTj3p9eoCnewXc9 ZHWXLMoX9pMXzAQAIyrDFpTdHk5AgN43PHhL7D00D0Efp8k8aAxfkIDZC6Gnje1mfqPc 3lHBKS39MfDlStphu6C8Jql2kQXfGmV1fgilEFItMJkx/1j/ZcEDj/0Xbs8iyBoY353i AK1Q== X-Gm-Message-State: APjAAAUc4UgsIoWL5GHt90qLuMA5nsFrGW62VtlvMBTLfWfaQZqyUvrm mpBIeJw7KrrECLOVL6whuaIf7YjB X-Google-Smtp-Source: APXvYqwggF6fTGffEYdom27G2h8zdV7J6CtTiN5KyewbCM+HJR0zr/h9+zNkyGTlnzn8+V1NmnNPJg== X-Received: by 2002:a5d:4205:: with SMTP id n5mr22543132wrq.52.1566152897352; Sun, 18 Aug 2019 11:28:17 -0700 (PDT) Received: from localhost.localdomain (x4db53457.dyn.telefonica.de. [77.181.52.87]) by smtp.gmail.com with ESMTPSA id c201sm24112584wmd.33.2019.08.18.11.28.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Aug 2019 11:28:16 -0700 (PDT) From: =?utf-8?q?SZEDER_G=C3=A1bor?= To: git@vger.kernel.org Cc: Junio C Hamano , Thomas Rast , Derrick Stolee , =?utf-8?q?SZEDER_G=C3=A1bor?= Subject: [RFC PATCH 5/5] line-log: try to use generation number-based topo-ordering Date: Sun, 18 Aug 2019 20:28:01 +0200 Message-Id: <20190818182801.7580-6-szeder.dev@gmail.com> X-Mailer: git-send-email 2.23.0.349.g73f10e387d In-Reply-To: <20190818182801.7580-1-szeder.dev@gmail.com> References: <20190818182801.7580-1-szeder.dev@gmail.com> MIME-Version: 1.0 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The previous patch made it possible to perform line-level filtering during history traversal instead of in an expensive preprocessing step, but it still requires some simpler preprocessing steps, notably topo-ordering. However, nowadays we have commit-graphs storing generation numbers, which make it possible to incrementally traverse the history in topological order, without the preparatory limit_list() and sort_in_topological_order() steps; see b45424181e (revision.c: generation-based topo-order algorithm, 2018-11-01). This patch combines the two, so we can do both the topo-ordering and the line-level filtering during history traversal, eliminating even those simpler preprocessing steps, and thus further reducing the delay before showing the first commit modifying the given line range. The 'revs->limited' flag plays the central role in this, because, due to limitations of the current implementation, the generation number-based topo-ordering is only enabled when this flag remains unset. Line-level log, however, always sets this flag in setup_revisions() ever since the feature was introduced in 12da1d1f6f (Implement line-history search (git log -L), 2013-03-28). The reason for setting 'limited' is unclear, though, because the line-level log itself doesn't directly depend on it, and it doesn't affect how the limit_list() function limits the revision range. However, there is an indirect dependency: the line-level log requires topo-ordering, and the "traditional" sort_in_topological_order() requires an already limited commit list since e6c3505b44 (Make sure we generate the whole commit list before trying to sort it topologically, 2005-07-06). The new, generation numbers-based topo-ordering doesn't require a limited commit list anymore. So don't set 'revs->limited' for line-level log, unless it is really necessary, namely: - The user explicitly requested parent rewriting, because that is still done in the line_log_filter() preprocessing step (see previous patch), which requires sort_in_topological_order() and in turn limit_list() as well. - A commit-graph file is not available or it doesn't yet contain generation numbers. In these cases we had to fall back on sort_in_topological_order() and in turn limit_list(). The existing condition with generation_numbers_enabled() has already ensured that the 'limited' flag is set in these cases; this patch just makes sure that the line-level log sets 'revs->topo_order' before that condition. While the reduced delay before showing the first commit is measurable in git.git, it takes a bigger repository to make it clearly noticable. In both cases below the line ranges were chosen so that they were modified rather close to the starting revisions, so the effect of this change is most noticable. # git.git $ time git --no-pager log -L:read_alternate_refs:sha1-file.c -1 v2.23.0 Before: real 0m0.107s user 0m0.091s sys 0m0.013s After: real 0m0.058s user 0m0.050s sys 0m0.005s # linux.git $ time git --no-pager log \ -L:build_restore_work_registers:arch/mips/mm/tlbex.c -1 v5.2 Before: real 0m1.129s user 0m1.061s sys 0m0.069s After: real 0m0.096s user 0m0.087s sys 0m0.009s Signed-off-by: SZEDER Gábor --- Notes: FWIW, that line-level log sets 'limited' in addition to 'topo_order' thing was already part of the first submitted iteration of the line-level log patch series: https://public-inbox.org/git/1277558857-23103-4-git-send-email-struggleyb.nku@gmail.com/#Z30revision.c But it was never discussed during review. revision.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/revision.c b/revision.c index 6bdfcb38cd..7a9dc54771 100644 --- a/revision.c +++ b/revision.c @@ -2658,6 +2658,12 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s if (revs->diffopt.objfind) revs->simplify_history = 0; + if (revs->line_level_traverse) { + if (want_ancestry(revs)) + revs->limited = 1; + revs->topo_order = 1; + } + if (revs->topo_order && !generation_numbers_enabled(the_repository)) revs->limited = 1; @@ -2677,11 +2683,6 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, struct s revs->diffopt.abbrev = revs->abbrev; - if (revs->line_level_traverse) { - revs->limited = 1; - revs->topo_order = 1; - } - diff_setup_done(&revs->diffopt); grep_commit_pattern_type(GREP_PATTERN_TYPE_UNSPECIFIED,