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

From: Thomas Rast <trast@inf.ethz.ch>
Date: Apr 22, 2013, 15:24 UTC
Message-ID: <87wqruk2pj.fsf@linux-k42r.v.cablecom.net>
In-Reply-To: <CALkWK0m6vwR9rNNw_GjF4MOK1GZfwjB8ZA5Y0Lo8LbvfAg0g3g@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 23 quoted lines

> 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