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

Re: Strange behavior of git rev-list

From
Jeff King <peff@peff.net>
Date
Sep 7, 2017, 10:11 UTC
Message-ID
<20170907101126.u574pr7l5odff6zo@sigill.intra.peff.net>
In-Reply-To
<CACNsYJ8rRSf5gNtnPS05CnYCYGmoBymbgH7UumuOuBz1jp6RBA@mail.gmail.com>
On Thu, Sep 07, 2017 at 11:50:25AM +0200, Paweł Marczewski wrote:
> Thanks. Any plans to fix that? Or is there a way to turn off this heuristic?

I don't think there's a way to turn it off for `rev-list`. Merge-base computations are more careful, so you could determine the correct endpoints that way. But when you fed them to `rev-list`, it would hit the same run of skewed commits.

We've discussed storing true generation numbers in the past, which would make this optimization more robust, as well as allow us to speed up many other traversals (e.g., the "tag --contains"). It's something I'd like to revisit, but it's not at the top of the pile.

In the meantime, it would probably be possible to write a patch that conditionally disables the optimization. But it would mean all of your rev-lists run a _lot_ slower.

-Peff
Previous: Paweł MarczewskiNext: Stefan Beller
Message 4 of 8 in “Strange behavior of git rev-list”
  1. Paweł MarczewskiSep 7, 2017
  2. Jeff KingSep 7, 2017
  3. Paweł MarczewskiSep 7, 2017
  4. Jeff KingSep 7, 2017
  5. Stefan BellerSep 7, 2017
  6. Jeff KingSep 8, 2017
  7. Junio C HamanoSep 8, 2017
  8. Jeff KingSep 8, 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.