Re: [RFC] git blame-tree

From: Jeff King <peff@peff.net>
Date: Mar 2, 2011, 21:10 UTC
Message-ID: <20110302211035.GC20400@sigill.intra.peff.net>
In-Reply-To: <AANLkTi=m_WTohMfJZxTqObRT3rhhtxo=QfnDJCHO=U0K@mail.gmail.com>

On Wed, Mar 02, 2011 at 07:39:20PM +0100, Piotr Krukowiecki wrote:

Show 10 quoted lines

> I'd expect this to be something like union. Currently I can only think about
> following case:
> 
> Some files were changed in branch1, some in branch2, some in both.
> Show me how the files are changed. For example:
>   file1 changed in branch1 in commit1
>   file2 changed in branch2 in commit2
>   file3 changed in branch1 in commit3 and in branch2 in commit4
> 
> If file was not changed since branch creation then don't show it (optionally).

I think we are getting into something different here, because you are caring not just about the commit in some traversal that touched a file, but for each source, which commits got us there and potentially multiple such commits, one per source for each file.

And that's a bit more expensive to compute, and the answers are not always unambiguous. For example, let's say branch1 and branch2 fork from some merge-base M. In the parent of M, file "foo" was changed. We traverse from branch1 and branch2, not seeing anything interesting for "foo". We hit M, and then finally see that its parent touched "foo".

What do we output? Both branches have equal claim to the commit.

I think you could figure out semantics that make sense if you spent enough time on it. But I also think it is making the relatively simple problem of blame-tree a lot more complex.

-Peff