From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id 8ADDB20450 for ; Fri, 3 Nov 2017 15:02:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752235AbdKCPCO (ORCPT ); Fri, 3 Nov 2017 11:02:14 -0400 Received: from pb-smtp1.pobox.com ([64.147.108.70]:50194 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751370AbdKCPCN (ORCPT ); Fri, 3 Nov 2017 11:02:13 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6E9A6A1BFE; Fri, 3 Nov 2017 11:02:12 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=0WVE3non4mK2JY8SvxPI/WxTtLE=; b=ng4klY nldkzaN59TWkJJGNv79REjP5ep42gkmFYBq6rpqed1YnXzEZQB/SFKrD1h4Zdj7s U11JpG4RG4VlbQxStnyqGpYM/FkGDRi8KtnxZh0V+EDHqN3t7+D/Ko7coJXTRc2Y HTWPqka1xhqHo4uMATUtI8eItOaZnihk48wCw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=M+JIjTNd6DqXyuZrakbNz8SYrZx+wNbg 0eGYtbFbXlLepN9RZYXmzMyPHAUg6a31on3PJV5tiOvZU8gLbv+sOotDGLg5aHJo RT7L5uykC+GABzF/1oTPwIeC6NtC7ofYGE4sX0O65Uxcc0CjljwHyq9r7xvmONqp fpeLombewtM= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 62F7AA1BFD; Fri, 3 Nov 2017 11:02:12 -0400 (EDT) Received: from pobox.com (unknown [104.132.0.95]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id C8AEBA1BFC; Fri, 3 Nov 2017 11:02:11 -0400 (EDT) From: Junio C Hamano To: git Cc: Johannes Schindelin , Stefan Beller , Kevin Daudt , Jacob Keller Subject: Re: [PATCHv2 6/7] builtin/describe.c: describe a blob References: <20171031003351.22341-1-sbeller@google.com> <20171031211852.13001-1-sbeller@google.com> <20171031211852.13001-7-sbeller@google.com> Date: Sat, 04 Nov 2017 00:02:10 +0900 In-Reply-To: (Jacob Keller's message of "Thu, 2 Nov 2017 23:55:32 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: F871EDEC-C0A7-11E7-B8C3-8EF31968708C-77302942!pb-smtp1.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Jacob Keller writes: > On Thu, Nov 2, 2017 at 10:18 PM, Junio C Hamano wrote: >> ... >> It is easy to imagine that we can restrict "git log" traversal with >> a "--blobchange=" option instead of (or in addition to) the >> limitation gives us. Instead of treating a commit whose >> diff against its parent commit has any filepair that is different >> within as "!TREESAME", we can treat a commit whose diff >> against its parent commit has a filepair that has the on >> either side of the filepair as "!TREESAME" (in other words, we >> ignore a transition that is not about introducing or forgetting the >> we are looking for as an "interesting change"). That would >> give you a commit history graph in which only (and all) such commits >> that either adds or removes the in it. >> >> Hmm? > > This seems quite useful in the context of figuring out how a file got > to such a state. This is useful to me, since if I know the state of a > file (ie: it's exact contents) I can determine the blob name, and then > use that to lookup where it was introduced. This is probably a bit harder than an average #leftoverbits, but if somebody wants to get their hands dirty, it should be reasonably straightforward. The needed changes would roughly go like so: - Add "struct oid *blob_change;" to diff_options, initialized to NULL. - Teach diff_opt_parse() a new option "--blobchange=". Allocate a struct oid when you parse this option and point at it with the blob_change field above. - Write diffcore-blobchange.c, modeled after diffcore-pickaxe.c, but this should be a lot simpler (as there is no need for an equivalent for "pickaxe-all" option). It would - prepare an empty diff_queue_struct "outq"; - iterate over the given diff_queue "q", and - a filepair p whose p->one is blob_change and p->two is not, (or the other way around) is added to outq with diff_q() - a filepair whose p->one/p->two do not involve blob_change is freed with diff_free_filepair(). - replace "q" with "outq". - Add a call to diffcore_blobchange() early in diffcore_std(), probably immediately after skip-stat-unmatch, when blob_change field is not NULL. - Arrange that blob_change is propagated to revs->pruning in setup_revisions().