> In the case of Pinboard, that operation would be fetching more than 2,500 branches.
Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?
Ok, I'll ask: why does a single repository have over 2,500 branches? Why not delete the ones you no longer use?
The example in the article is a bit of a special case. It is a huge, and old, monorepo. In the typical case, fetching everything and fetching master is equivalent because all commits in all branches make their way into master anyway. If you have a weird branching strategy where you maintain multiple, significantly diverged branches at once, but only care about one of those branches at build time, then this optimization would save you time.
Squash merges leave a ton of commits just floating in your old branch. If you delete the branch (the 40B file), all those commits are still there. Doing lots of squash merges brings you into this case I mentioned:
> If you have a weird branching strategy where you maintain multiple, significantly diverged branches at once, but only care about one of those branches at build time, then this optimization would save you time.
Based on the article linked here, they do.
Its not the fact that they had lots of branches itself, its the fact that they had lots of commits hanging out in the middle of nowhere.
That is if we assume they copy google's philosophy of a single monolith repository.
Pinterest has about 2000 employees, assuming 20% are active developers thats about 400 people, that gives you roughly 6 branches per developer which wouldn't be outrageous.