On Fri, Dec 8, 2017 at 12:19 PM, Jeff King <peff@xxxxxxxx> wrote: > 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. :) Thanks for digging. I came to a similar realization. > 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. We should when --raw is given. --raw is documented as "For each commit, show a summary of changes using the raw diff format." and I would argue that 'each commit' includes merges. Though I guess this may have implications for long time users. > 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. yup, hidden merges are unfortunate. Is there an easy way to find out about merges? (Junio hints at having tests around merges, which I'll do next)
