On Thu, Nov 2, 2017 at 10:18 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jacob Keller <jacob.keller@xxxxxxxxx> 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? 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. Thanks, Jake
