Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com 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.
Junio C Hamano gits...@pobox.com 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,
Bernhard R. Link brl...@debian.org 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
* Junio C Hamano gits...@pobox.com [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
Bernhard R. Link brl+...@mail.brlink.eu writes:
* Junio C Hamano gits...@pobox.com [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
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
6 matches
Mail list logo
