git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?

From
TCTomas Carnecky <tomas.carnecky@gmail.com>
Date
Dec 22, 2009, 18:18 UTC
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:
Show 57 quoted lines
> 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
Previous: Junio C HamanoNext: Tomas Carnecky
Message 3 of 4 in “Where did Documentation/perf_counter disappear from linux-2.6-tip.git ?”
  1. Tomas CarneckyDec 22, 2009
  2. Junio C HamanoDec 22, 2009
  3. Tomas CarneckyDec 22, 2009
  4. Tomas CarneckyDec 22, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.