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

2014-01-14 Thread Junio C Hamano
Junio C Hamano writes: > The "pick the one that exactly matches if exists" can be thought of > an easy hack to hide the problems that come from this arbitrary > choice. ... > Instead, "pass the whole blame to the one that exactly matches" hack > keeps larger blocks of text unsplit, clumping rela

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

2014-01-14 Thread Junio C Hamano
Junio C Hamano writes: > Junio C Hamano writes: > >>> While the result is more consistent and more predictable in the case >>> of merged cherry picks, it is also slower in every case. >> >> Consistent and predictable, perhaps, but I am not sure "exact" would >> be a good word. > > Another thing

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

2014-01-13 Thread Junio C Hamano
Junio C Hamano writes: >> While the result is more consistent and more predictable in the case >> of merged cherry picks, it is also slower in every case. > > Consistent and predictable, perhaps, but I am not sure "exact" would > be a good word. Another thing I am not enthusiasitc about this cha

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

2014-01-13 Thread Junio C Hamano
"Bernhard R. Link" writes: > * Junio C Hamano [140113 23:31]: >> I read the updated documentation three times but it still does not >> answer any of my questions I had in $gmane/239888, the most >> important part of which was: >> >> Yeah, the cherry-picked one will introduce the same change

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

2014-01-13 Thread Bernhard R. Link
* Junio C Hamano [140113 23:31]: > I read the updated documentation three times but it still does not > answer any of my questions I had in $gmane/239888, the most > important part of which was: > > Yeah, the cherry-picked one will introduce the same change as > the one that was cherry-pic

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

2014-01-13 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. > > This optimization, while being faster in the usual case, means that in > the

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

2014-01-12 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