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

Tomas Carnecky [off-list ref] 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 [off-list ref]
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.

On 12/22/09 7:08 PM, Junio C Hamano wrote:

Tomas Carnecky[off-list ref]  writes:

quoted

  $ 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[off-list ref]
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