[RFC] blame: new option to better handle merged cherry-picks

2014-01-02 Thread Bernhard R. Link
Allows to disable the git blame optimization of assuming that if there is a parent of a merge commit that has the exactly same file content, then only this parent is to be looked at. This optimization, while being faster in the usual case, means that in the case of cherry-picks the blamed commit d

Re: [RFC] blame: new option to better handle merged cherry-picks

2014-01-02 Thread Junio C Hamano
"Bernhard R. Link" writes: > Allows to disable the git blame optimization of assuming that if there is a > parent of a merge commit that has the exactly same file content, then > only this parent is to be looked at. I think this is what we usually call --full-history in "git log" family, but mor

Re: [RFC] blame: new option to better handle merged cherry-picks

2014-01-02 Thread Bernhard R. Link
* Junio C Hamano [140102 21:29]: > > This optimization, while being faster in the usual case, means that in > > the case of cherry-picks the blamed commit depends on which other commits > > touched a file. > > > > If for example one commit A modified both files b and c. And there are > > commits B

Re: [RFC] blame: new option to better handle merged cherry-picks

2014-01-02 Thread Junio C Hamano
"Bernhard R. Link" writes: > When giving git-blame the new option introduced with my patch, only > the order of parents determines which commit is blamed. Without > the option (i.e. the currently only possible behaviour) which commit > is blamed depends what else touches other parts of the file.