Re: [RFC] git blame-tree

[Piotr Krukowiecki <piotr.krukowiecki@gmail.com>]

On Wed, Mar 2, 2011 at 10:10 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Mar 02, 2011 at 07:39:20PM +0100, Piotr Krukowiecki wrote:
>
>> 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.

Yah, it might be something for git-log or git-diff.


> 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".

So it's like this?

B1
|
M - B2
|
P <- changes foo


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

That's easy. In "show only differences" we don't show anything,
because on both branches last-change-commit of "foo" is the same.
In "show all" last-change-commit is P so show it (with message like
"changed in common root" or whatever).


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

I think this is simple, but maybe I don't understand some git
internals that make it hard.


-- 
Piotrek