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

[PATCH v2 3/3] object-name: don't try to abbreviate to lengths greater than hexsz

From
Patrick Steinhardt <ps@pks.im>
Date
Jun 12, 2024, 08:03 UTC
Message-ID
<0ccb8d8efa4010c4a7ba00ca1abe7f3e923843ed.1718178996.git.ps@pks.im>
In-Reply-To
<cover.1718178996.git.ps@pks.im>

When given a length that equals the current hash algorithm's hex size, then `repo_find_unique_abbrev_r()` exits early without trying to find an abbreviation. This is only sensible because there is nothing to abbreviate in the first place, so searching through objects to find a unique prefix would be a waste of compute.

What we don't handle though is the case where the user passes a length greater than the hash length. This is fine in practice as we still compute the correct result. But at the very least, this is a waste of resources as we try to abbreviate a value that cannot be abbreviated, which causes us to hit the object database.

Start to explicitly handle values larger than hexsz to avoid this performance penalty, which leads to a measureable speedup. The following benchmark has been executed in linux.git:

  Benchmark 1: git -c core.abbrev=9000 log --abbrev-commit (revision = HEAD~)
    Time (mean ± σ):     12.812 s ±  0.040 s    [User: 12.225 s, System: 0.554 s]
    Range (min … max):   12.723 s … 12.857 s    10 runs
  Benchmark 2: git -c core.abbrev=9000 log --abbrev-commit (revision = HEAD)
    Time (mean ± σ):     11.095 s ±  0.029 s    [User: 10.546 s, System: 0.521 s]
    Range (min … max):   11.037 s … 11.122 s    10 runs
  Summary
    git -c core.abbrev=9000 log --abbrev-commit HEAD (revision = HEAD) ran
      1.15 ± 0.00 times faster than git -c core.abbrev=9000 log --abbrev-commit HEAD (revision = HEAD~)
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
 object-name.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/object-name.c b/object-name.c
index 523af6f64f..1be2ad1a16 100644
--- a/object-name.c
+++ b/object-name.c
@@ -837,7 +837,7 @@ int repo_find_unique_abbrev_r(struct repository *r, char *hex,
 	}
 
 	oid_to_hex_r(hex, oid);
-	if (len == hexsz || !len)
+	if (len >= hexsz || !len)
 		return hexsz;
 
 	mad.repo = r;
-- 
2.45.2.457.g8d94cfb545.dirty
Previous: Patrick SteinhardtNext: Karthik Nayak
Message 13 of 14 in “SEGV (detected by Address Sanitizer) when using `core.abbrev` option”
  1. Kyle LippincottJun 10, 2024
  2. Kyle LippincottJun 10, 2024
  3. Junio C HamanoJun 10, 2024
  4. Patrick SteinhardtJun 11, 2024
  5. 1/2 config: fix segfault when parsing "core.abbrev" without repoPatrick Steinhardt, Jun 11, 2024
  6. Junio C HamanoJun 11, 2024
  7. Patrick SteinhardtJun 12, 2024
  8. 2/2 object-name: don't try to abbreviate to lengths greater than hexszPatrick Steinhardt, Jun 11, 2024
  9. 0/3 config: fix segfault when parsing "core.abbrev" without repoPatrick Steinhardt, Jun 12, 2024
  10. 1/3 config: fix segfault when parsing "core.abbrev" without repoPatrick Steinhardt, Jun 12, 2024
  11. Karthik NayakJun 12, 2024
  12. 2/3 parse-options-cb: stop clamping "--abbrev=" to hash lengthPatrick Steinhardt, Jun 12, 2024
  13. 3/3 object-name: don't try to abbreviate to lengths greater than hexszPatrick Steinhardt, Jun 12, 2024
  14. Karthik NayakJun 12, 2024

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.