From: Tomas Carnecky <tomas.carnecky@gmail.com>
Date: Tue, 22 Dec 2009 18:18:40 GMT
Subject: Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?
Message-ID: <4B310D80.4010502@gmail.com>
In-Reply-To: <7vmy1a3mrh.fsf@alter.siamese.dyndns.org>

On 12/22/09 7:08 PM, Junio C Hamano wrote:
> Tomas Carnecky<tomas.carnecky@gmail.com>  writes:
>
>>   $ git --version
>> git version 1.6.6.rc4
>>
>> # Documentation/perf_counter is missing from the master branch, so
>> first let's find
>> # out what the last commit was that touched that subdirectory:
>> $ git log --all -1 -- Documentation/perf_counter
>> commit 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> Author: Peter Zijlstra<a.p.zijlstra@chello.nl>
>> Date:   Tue Jun 2 21:02:36 2009 +0200
>> ...
>> M       Documentation/perf_counter/builtin-report.c
>>
>> # Great, let's look in which branch that commit is
>> $ git branch --contains 436224a6d8bb3e29fe0cc18122f8d1f593da67b8
>> * master
>>
>> # So, let's look at the log of master and limit it to that subdirectory:
>> $ git log master -- Documentation/perf_counter
>> $
>
> Add --full-history so that you would get _all_ possible explanation of the
> history, perhaps?
>
> In a history with this shape:
>
>      ---A---B---C---D---E
>              \     /
>               F---G
>
> suppose that
>
>   - commit F introduces a path;
>   - commit G removes the path;
>   - no other commit has the path in question.
>
> Without --full-history, "log E -- path" is asked to give "_one_ possible
> way to explain the current state of path in E" (iow, "why there is nothing
> there right now at E?").
>
> Two explanations are possible even in this vastly simplified toy history.
>
>   - It didn't exist in A, and none of the subsequent commits B, C, D that
>     lead to E did anything to change that.
>
>   - F added it, but G changed mind and removed it.
>
> When "log" encounters a merge commit while traversing the history
> backwards (in this case D) with paths limiter, if there is a commit among
> its parent whose tree matches its tree with respect to the paths, side
> branches leading to all the other parents are culled and only that one
> history is followed to explain the history.  In this case, neither C or D
> has the path, so their trees with respect to the paths limiter match, and
> git doesn't follow the side branch that has F and G without
> --full-history.

I've never used nor seen --full-history before, but it did help in this 
case, git log now correctly sees the commits touching that subdirectory. 
Thanks for the explanation.

tom