Re: [PATCHv2 6/7] builtin/describe.c: describe a blob

From: Junio C Hamano <gitster@pobox.com>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Stefan Beller <sbeller@google.com>, git <git@vger.kernel.org>,
	Kevin Daudt <me@ikke.info>
Subject: Re: [PATCHv2 6/7] builtin/describe.c: describe a blob
Date: Fri, 03 Nov 2017 14:18:24 +0900	[thread overview]
Message-ID: <xmqqtvycos7z.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CA+P7+xqw9zKNUkn9P-qA57ADSB5G_7Sd0JCc6SaK6bBf9-Jhtg@mail.gmail.com> (Jacob Keller's message of "Wed, 1 Nov 2017 23:05:00 -0700")

Jacob Keller <jacob.keller@gmail.com> writes:

> I think both questions are valuable, the first is "which commit last
> had this blob", the second  is "which commit first introduced this
> blob", neither of which can always give a definitive answer. It really
> depends on what question you're asking up front.

Given that "describe" is about giving an object _a_ name that is
plausibly useful to refer to it, it is not a good match for the
above query that wants to know where it came from, how long it
remains in the tree and where it ceases to be relevant.  In order to
support that use case, a totally different and possibly more useful
avenue would be to think how this can be hooked into "git log"
machinery.

A refresher for how "git log [--options] <pathspec>" works may be
beneficial.  We walk history and compare the tree of the commit we
are looking at with the tree of its parent commits.  If everything
within <pathspec> is the same, we mark the transition between the
parent and our commit TREESAME (other commits, i.e. the ones that
have meaningful change within <pathspec>, are !TREESAME).  Then the
output routine presents the set of commits that includes commits
that are !TREESAME, within the constraints of the --options given
(e.g. with --full-history, sides of a merge that is TREESAME may
still be shown to preserve connectedness of the resulting graph).

It is easy to imagine that we can restrict "git log" traversal with
a "--blobchange=<blob>" option instead of (or in addition to) the
limitation <pathspec> gives us.  Instead of treating a commit whose
diff against its parent commit has any filepair that is different
within <pathspec> as "!TREESAME", we can treat a commit whose diff
against its parent commit has a filepair that has the <blob> on
either side of the filepair as "!TREESAME" (in other words, we
ignore a transition that is not about introducing or forgetting the
<blob> 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 <blob> in it.

Hmm?