Page MenuHomePhabricator

Skip "git for-each-ref" when identifying deleted commits
ClosedPublic

Authored by epriestley on Mar 28 2021, 5:58 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 6, 7:04 AM
Unknown Object (File)
Tue, Dec 3, 12:58 PM
Unknown Object (File)
Mon, Nov 11, 2:38 AM
Unknown Object (File)
Nov 4 2024, 10:49 AM
Unknown Object (File)
Nov 4 2024, 10:49 AM
Unknown Object (File)
Nov 4 2024, 10:49 AM
Unknown Object (File)
Nov 3 2024, 2:01 AM
Unknown Object (File)
Nov 1 2024, 5:14 AM
Subscribers
None

Details

Summary

Ref T13647. The ref discovery process prunes commits that no longer exist in the repository before executing "git log <new heads> --not <old heads>" to identify newly published commits.

If we don't do this, the "git log" command will fail if any old head has been pruned from the repository.

Currently, this test for missing commits starts with a call to "git for-each-ref" to attempt to resolve symbols as tag or branch names, but:

  • this is painfully slow in repositories with many refs; and
  • this is incorrect (not consistent with "git" behavior) for 40-character hex strings, which Git will never resolve as symbolic names.

Instead, when a symbol is a 40-character hex string, skip "git for-each-ref" and jump directly to "git cat-file --batch-check".

Test Plan
  • Ran bin/repository update in a repository with 65K refs and extra debugging info.
    • Before: took ~30s, three calls to git for-each-ref.
    • After: took ~20s, two calls to git for-each-ref. Same resolution result on queries.

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable