Re: [PATCH] t4202 (log): add failing test for log with subtree

[Ramkumar Ramachandra <artagnon@gmail.com>]

Thomas Rast wrote:
> So (I think?) in the above you claim that $USER interprets
>
>   git log -- README.md
>
> as
>
>   Show me the history of README.md.
>
> But there's no such thing as the history of a file!

I made no such claims.  I might not know as much as you or the others
on the list about git, but I can certainly grok how git stores
history.

There needs to be some amount of mutual respect for a healthy
conversation: if you start assuming midway that I don't understand
what history is, we have a problem.

> So please don't write tests that go contrary to that definition, because
> they're *wrong*.  The current implementation precisely matches the
> current definition of pathspec filtering.

Who said anything about changing any definitions?  Where are you
getting all this from?

How does "git log HEAD~3 -- README" work?  It sets up a revision walk
to start from HEAD~3 going all the way down to the root commit.  In
each of these commits, it looks for the entry "README" in the
corresponding tree.  It then runs diff-tree with the previous commit's
tree to see if the object (blob) corresponding to the "README" entry
is different: if so, it selects the commit and displays it.

Now, what am I saying?  I'm saying that this approach assumes that all
trees are read into /.  A pathspec "subproject/README" is _only_
present in the subtree-merge commit^{tree} and nowhere else.  The
current log algorithm might try to look for the entry
"subproject/README" (your pathspec) in all the commit^{tree}s of the
commits leading up to M^2.  That is _not_ the problem, as I have
already illustrated that --follow follows over merges.  The problem is
looking for the pathspec "subproject/README" in the first place: those
commit^{trees}s have the entry stored as "README".

Am I making any sense, or are you going to accuse me of not
understanding trees now?