Kevin Bracey <ke...@bracey.fi> writes:
> I think I've found the problem. It only doesn't work _if you specify
> the file_.
>
> Specifically, if I was missing an addition, my first attempt to find
> it would be
>
> git log -p -m -S<addition> <file>
>
> If the addition was lost in a merge, that doesn't even show the
> addition, which is surprising, but intentional. The addition isn't
> part of the HEAD version of <file>, so no point going down that path
> of the merge. Fine. However, I expected this to work:
>
> git log --full-history -p -m -S<addition> <file>
>
> But it doesn't. It finds the addition, but _not_ the loss in the merge
> commit.
>
> But this does work:
>
> git log -p -m -S<addition>
>
> That really feels like a bug to me. By specifying a file, I've made it
> miss the change, and I can see no way to get the change without making
> it a full-tree operation.
> ... But I'd like some way to find merges
> that drop code in a specified file, and surely "--full-history" is it?
Yeah, I think that is a bug.
$ echo first >file
$ git add file && git commit -m initial
$ git checkout -b side
$ echo second >file && git commit -a -m side
$ git checkout - && >file && git add file && git commit -m lose
$ git merge -s ours -m lost side
$ git log -p -m --full-history -Ssecond -1 file
does not seem to find the commit that lost the line.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
