Given the hash of a blob, is there a way to get a list of commits that have this blob in their tree?
Given the hash of a blob, is there a way to get a list of commits that have this blob in their tree?
With Git 2.16 (Q1 2018), git describe would be a good solution, since it was taught to dig trees deeper to find a
that refers to a given blob object.
See commit 644eb60, commit 4dbc59a, commit cdaed0c, commit c87b653, commit ce5b6f9 (16 Nov 2017), and commit 91904f5, commit 2deda00 (02 Nov 2017) by Stefan Beller (stefanbeller).
(Merged by Junio C Hamano -- gitster -- in commit 556de1a, 28 Dec 2017)
builtin/describe.c: describe a blob
Sometimes users are given a hash of an object and they want to identify it further (ex.: Use
verify-pack
to find the largest blobs, but what are these? or this very SO question "Which commit has this blob?")When describing commits, we try to anchor them to tags or refs, as these are conceptually on a higher level than the commit. And if there is no ref or tag that matches exactly, we're out of luck.
So we employ a heuristic to make up a name for the commit. These names are ambiguous, there might be different tags or refs to anchor to, and there might be different path in the DAG to travel to arrive at the commit precisely.When describing a blob, we want to describe the blob from a higher layer as well, which is a tuple of
(commit, deep/path)
as the tree objects involved are rather uninteresting.
The same blob can be referenced by multiple commits, so how we decide which commit to use?This patch implements a rather naive approach on this: As there are no back pointers from blobs to commits in which the blob occurs, we'll start walking from any tips available, listing the blobs in-order of the commit and once we found the blob, we'll take the first commit that listed the blob.
For example:
git describe --tags v0.99:Makefile conversion-901-g7672db20c2:Makefile
tells us the
Makefile
as it was inv0.99
was introduced in commit 7672db2.The walking is performed in reverse order to show the introduction of a blob rather than its last occurrence.
That means the git describe man page adds to the purposes of this command:
Instead of simply describing a commit using the most recent tag reachable from it,
git describe
will actually give an object a human readable name based on an available ref when used asgit describe
.If the given object refers to a blob, it will be described as
, such that the blob can be found at
: in the
, which itself describes the first commit in which this blob occurs in a reverse revision walk from HEAD.
But:
BUGS
Tree objects as well as tag objects not pointing at commits, cannot be described.
When describing blobs, the lightweight tags pointing at blobs are ignored, but the blob is still described asdespite the lightweight tag being favorable.
: