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

[Thomas Rast <trast@inf.ethz.ch>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Thomas Rast wrote:
>> [...]
>
> I think you've misunderstood the whole thing.  The histories of M^1
> and M^2 are completely unrelated: they're from different projects
> altogether.  Considering the /ichi in M^2 a "rename" of the /ichi in
> M^1 is completely wrong.  They have nothing to do with each other.  I
> intentionally named it "ichi" in my orphan branch just to drive my
> point.  I suspect you've got confused because I used an orphan branch
> to emulate a different project's history.  If you want an end-user
> understanding of the problem, use git subtree:
>
>     $ cd /tmp
>     $ git clone gh:artagnon/varlog
>     $ cd varlog
>     $ git subtree add --prefix=clayoven \
>        gh:artagnon/clayoven master
>     $ cd clayoven
>     $ git log README.md
>
> What do you expect?  The same output you would get if you cloned
> gh:artagnon/clayoven separately and executed 'git log README.md' on
> it.

No, I don't.  But that's probably because I know a few things about how
git-log works that your hypothetical $USER doesn't.

At the risk of restating what everyone agrees on: It's a design
principle of git that it only stores tree states, and anything about
diffs, files, renames, etc. is purely in the imagination of the user.

We support that imagination by having analysis tools with which some
things can be found out, but others can't.

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!  The command instead
says

  If I filter all history for only changes affecting a path 'README.md'
  in the root of the repository[1], then what does it look like?


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.

You can try arguing for changing the definition, but unless you find one
that can be implemented fast enough to be generally usable, I will
oppose that change.


The only thing that's broken in any of this is that I think, as
explained on IRC, that a hypothetical fixed --follow -C should be able
to figure out this case.  By spending extra cycles on analysis,
naturally.


[1]  and also skipping lines of history that seem uninteresting at this
point already, compare --simplify-merges

-- 
Thomas Rast
trast@{inf,student}.ethz.ch