git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
UWUlrich Windl <ulrich.windl@rz.uni-regensburg.de>
Date
Apr 3, 2017, 06:56 UTC
Message-ID
<58E1F239020000A100025732@gwsmtp1.uni-regensburg.de>
In-Reply-To
<xmqq60ip1m0f.fsf@gitster.mtv.corp.google.com>
Junio,

thanks for explaining! So if there are at least two commits, blame is fast, but with only one commit blame tries hard to find another commit that might have contributed to the one file? I verified that without those "-C" options the result is very quick. In the other case (for the user bored of waiting seeking for some entertainment ;-)) a "-v (verbose) option could be useful. Or at the very least: If git is expecting that some operation will take (or already did take) a lot of time, give some message explaining why it is taking a lot of time, and maybe how to avoid that.

Regards, Ulrich

>>> Junio C Hamano <gitster@pobox.com> schrieb am 31.03.2017 um 17:52 in Nachricht
<xmqq60ip1m0f.fsf@gitster.mtv.corp.google.com>:
Show 23 quoted lines
> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> writes:
> 
>> I was running "vc-annotate" in Emacs for a file from a large
>> repository (>40000 files, a big percentage being binary, about 10
>> commits). For the first file the result was presented rather soon, but
>> for a second file the command did not finish even after about 10
>> minutes!
>>
>> The file in question is a rather short text file (124 kB), and
>> according to git log it has one commit.
>>
>> While being bored, I did an strace of the command to find out that a
>> huge number of files is inspected.
> 
> With -C -C the user (vc-annotate?) is asking to inspect huge number
> of files, to find if the contents of the file (except for the part
> that came from its own previous version) came from other existing
> files.  So this is very much expected.
> 
> 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).
Previous: Samuel LijinNext: SZEDER Gábor
Message 4 of 11 in “Terrible bad performance for it blame --date=iso -C -C master -- <file>”
  1. Ulrich WindlMar 31, 2017
  2. Junio C HamanoMar 31, 2017
  3. Samuel LijinMar 31, 2017
  4. Antw: Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>Ulrich Windl, Apr 3, 2017
  5. SZEDER GáborApr 3, 2017
  6. Jakub NarębskiApr 3, 2017
  7. Antw: Re: Terrible bad performance for it blame --date=iso -CUlrich Windl, Apr 4, 2017
  8. Samuel LijinMay 1, 2017
  9. Junio C HamanoMay 2, 2017
  10. Samuel LijinMay 3, 2017
  11. Antw: Re: Terrible bad performance for it blame --date=iso -C -C master -- <file>Ulrich Windl, May 3, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.