Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>

3 messages, 3 authors, 2017-05-03 · open the first message on its own page

Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>

From: Junio C Hamano <hidden>
Date: 2017-05-02 01:00:01

Samuel Lijin [off-list ref] writes:
On Fri, Mar 31, 2017 at 10:52 AM, Junio C Hamano [off-list ref] wrote:
quoted
It might not be a bad idea to teach "blame" not to pay attention to
any path that is marked as "-diff" (e.g. binary files) when trying
to see if remaining contents appeared by borrowing from them.  We do
not have that heuristics (yet).
Could you elaborate on this? Do you mean to tell diffcore-rename to
ignore diff_filespec objects if they're binary?
No and yes ;-).  I do not think it is a good idea to unconditionally
ignore binary in diffcore-rename.

But when we know that the rename detection is called from inside
blame.c, where by definition we would be digging line-oriented
contents, there is no point checking if the contents we are looking
for came from an existing binary file.

Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>

From: Samuel Lijin <hidden>
Date: 2017-05-03 07:12:52

On Mon, May 1, 2017 at 7:59 PM, Junio C Hamano [off-list ref] wrote:
Samuel Lijin [off-list ref] writes:
quoted
On Fri, Mar 31, 2017 at 10:52 AM, Junio C Hamano [off-list ref] wrote:
quoted
It might not be a bad idea to teach "blame" not to pay attention to
any path that is marked as "-diff" (e.g. binary files) when trying
to see if remaining contents appeared by borrowing from them.  We do
not have that heuristics (yet).
Could you elaborate on this? Do you mean to tell diffcore-rename to
ignore diff_filespec objects if they're binary?
No and yes ;-).  I do not think it is a good idea to unconditionally
ignore binary in diffcore-rename.

But when we know that the rename detection is called from inside
blame.c, where by definition we would be digging line-oriented
contents, there is no point checking if the contents we are looking
for came from an existing binary file.
A followup thought: perhaps it would make sense for blame.c rename
detection to only consider files with the same extension?

Antw: Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>

From: Ulrich Windl <hidden>
Date: 2017-05-03 12:29:51

quoted
quoted
Samuel Lijin [off-list ref] schrieb am 03.05.2017 um 09:12 in Nachricht
[off-list ref]:
On Mon, May 1, 2017 at 7:59 PM, Junio C Hamano [off-list ref] wrote:
quoted
Samuel Lijin [off-list ref] writes:
quoted
On Fri, Mar 31, 2017 at 10:52 AM, Junio C Hamano [off-list ref] wrote:
quoted
It might not be a bad idea to teach "blame" not to pay attention to
any path that is marked as "-diff" (e.g. binary files) when trying
to see if remaining contents appeared by borrowing from them.  We do
not have that heuristics (yet).
Could you elaborate on this? Do you mean to tell diffcore-rename to
ignore diff_filespec objects if they're binary?
No and yes ;-).  I do not think it is a good idea to unconditionally
ignore binary in diffcore-rename.

But when we know that the rename detection is called from inside
blame.c, where by definition we would be digging line-oriented
contents, there is no point checking if the contents we are looking
for came from an existing binary file.
A followup thought: perhaps it would make sense for blame.c rename
detection to only consider files with the same extension?
As traditionally file type and file name extension had little to do with each other in UNIX, I thing that would not be a good solution (to assume the opposite). I also know that Git does not care too much about hierarchies also, but my idea was so find candidates "nearby", i.e. look in the subdirectories of the first level and in the parent directory; then, if needed, widen the radius of the search...

Regards,
Ulrich




Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help