4 ms·
They weren't, if you look at the fix [1] the dedupe loop was run in all cases, not just those with known dupes, so the performance hit was any bundle with lots
by 6LLvveMx2koXfwn 1y ago
They weren't, if you look at the fix [1] the dedupe loop was run in all cases, not just those with known dupes, so the performance hit was any bundle with lots of refs.
1.https://github.com/git/git/commit/bb74c0abbc31da35be52999569ea481ebd149d1d#diff-62b8d8a0a9d03dad94f9847649a7d40443e70a9c81d4fb0cde32a8cdea829c61L569 https://github.com/git/git/commit/bb74c0abbc31da35be52999569...
- rjmunro 1y agoBut why couldn't they just dedupe the refs from the command line before starting the actual bundling - surely there are never more than a couple of hundred of those (one per branch)?
- 6LLvveMx2koXfwn 1y agoThe point is the performance hit had nothing to do with dupe count (which could be zero), and everything to do with ref count.
- nayak 1y agoSpot on. Some of our repositories at GitLab can contain millions of references.