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?
--
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