From: Jeff King <peff@peff.net>
To: Ramsay Jones <ramsay@ramsayjones.plus.com>
Cc: Stefan Beller <sbeller@google.com>, git@vger.kernel.org
Subject: Re: [PATCH 1/1] diffcore: add a filter to find a specific blob
Date: Fri, 8 Dec 2017 15:19:57 -0500 [thread overview]
Message-ID: <20171208201957.GA456@sigill.intra.peff.net> (raw)
In-Reply-To: <643e1afd-43e2-7fcc-452b-8b9ceac6868c@ramsayjones.plus.com>
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
next prev parent reply other threads:[~2017-12-08 20:20 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-08 0:24 [PATCH 0/1] diffcore-blobfind Stefan Beller
2017-12-08 0:24 ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-12-08 9:34 ` Jeff King
2017-12-08 16:28 ` Ramsay Jones
2017-12-08 20:19 ` Jeff King [this message]
2017-12-08 20:39 ` Stefan Beller
2017-12-08 21:38 ` Jeff King
2017-12-08 15:04 ` Junio C Hamano
2017-12-08 17:21 ` Junio C Hamano
2017-12-08 21:11 ` Stefan Beller
2017-12-08 21:15 ` Junio C Hamano
2017-12-11 19:58 ` [PATCH 0/1] diff-core blobfind Stefan Beller
2017-12-11 19:58 ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-12-11 23:17 ` Junio C Hamano
2017-12-12 0:21 ` Stefan Beller
2017-12-12 1:24 ` [PATCH] " Stefan Beller
2017-12-12 18:36 ` Junio C Hamano
2017-12-14 21:22 ` Jonathan Nieder
2017-12-14 22:30 ` Stefan Beller
2017-12-14 22:52 ` Jonathan Nieder
2017-12-15 2:18 ` Junio C Hamano
2017-12-27 18:49 ` Stefan Beller
2017-12-27 18:59 ` Jonathan Nieder
2017-12-27 19:57 ` Junio C Hamano
2017-12-14 22:44 ` Junio C Hamano
-- strict thread matches above, loose matches on Subject: below --
2017-11-20 22:25 [PATCH 0/1] Teaching the diff machinery about blobfind [WAS: git describe <blob>] Stefan Beller
2017-11-20 22:25 ` [PATCH 1/1] diffcore: add a filter to find a specific blob Stefan Beller
2017-11-24 7:43 ` Junio C Hamano
2017-11-25 4:59 ` Junio C Hamano
2017-12-07 21:40 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171208201957.GA456@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=ramsay@ramsayjones.plus.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).