On Fri, Dec 08, 2017 at 04:28:23PM +0000, Ramsay Jones wrote: > On 08/12/17 09:34, Jeff King wrote: > > On Thu, Dec 07, 2017 at 04:24:47PM -0800, Stefan Beller wrote: > [snip] > >> Junio hinted at a different approach of solving this problem, which this > >> patch implements. Teach the diff machinery another flag for restricting > >> the information to what is shown. For example: > >> > >> $ ./git log --oneline --blobfind=v2.0.0:Makefile > >> b2feb64309 Revert the whole "ask curl-config" topic for now > >> 47fbfded53 i18n: only extract comments marked with "TRANSLATORS:" > >> > >> we observe that the Makefile as shipped with 2.0 was introduced in > >> v1.9.2-471-g47fbfded53 and replaced in v2.0.0-rc1-5-gb2feb64309 by > >> a different blob. > > Sorry, this has nothing to do with this specific thread. :( > > However, the above caught my eye. Commit b2feb64309 does not 'replace > the Makefile with a different blob'. That commit was a 'last minute' > revert of a topic _prior_ to v2.0.0, which resulted in the _same_ > blob as commit 47fbfded53. (i.e. a53f3a8326c2e62dc79bae7169d64137ac3dab20).
Right, I think the patch is working as advertised but the commit message misinterprets the results. :) If you add --raw, you can see that both commits introduce that blob, and it never "goes away". That's because that happened in a merge, which we don't diff in a default log invocation. And in fact finding where this "goes away" is hard, because the merge doesn't trigger "-c" or "--cc". It's 8eaf517835, which presumably was forked before the revert in b2feb64309, and then the merge was able to replace that blob completely with the other side of the merge. Viewing with "-m" turns up a bunch of uninteresting merges. Looking at "--first-parent" is how I got 8eaf517835. So I think this one is tricky because of the revert. In the same way that pathspec-limiting is often tricky in the face of a revert, because the merges "hide" interesting things happening. -Peff
