3 ms·

it could have been longer. I still don't know why they were doing backup bundles with two refs :)

• 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 ago
    But 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 ago
      The 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 ago
        Spot on. Some of our repositories at GitLab can contain millions of references.