Re: Locating merge that dropped a change

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Bracey <kevin@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]