4 ms·

> 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

> 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?

casperb 6y ago
Probably because they have 1600 employees and the 2500 branches are the active ones.
tetris11 6y ago
If you have several releases with different targets, and want to make future security updates accessible to all
DoingIsLearning 6y ago
They could already be doing that. 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.
dahfizz 6y ago
Where I work doesn't delete branches, because there is no reason to. Git branches have essentially zero overhead and deleting them is just extra complexity in the CI toolchain. Deleting branches also deletes context in some scenarios. When dealing with an old codebase its nice to be able to checkout the exact version of the code at some point without having to dig through the log to get hashes and then dealing with a detached head. 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.
- richardwhiuk 6y ago
  If you are doing squash merges, git branches have a cost.
  - dahfizz 6y ago
    A git branch is literally a file with a commit hash in it. It's conceptually a pointer to a commit. Creating, destroying, and maintaining a branch has all the overhead of a ~40 byte file. 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.
- rovr138 6y ago
  > Git branches have essentially zero overhead Based on the article linked here, they do.
  - dahfizz 6y ago
    > 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. 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.
hn_throwaway_99 6y ago
Because they use a monorepo. With monorepos at large companies the individual git repositories will be much larger and contain a ton more branches than if you have a repository-per-project model.
est 6y ago
monorepo culture.

> 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?

casperb 6y ago

Probably because they have 1600 employees and the 2500 branches are the active ones.

tetris11 6y ago

If you have several releases with different targets, and want to make future security updates accessible to all

DoingIsLearning 6y ago

They could already be doing that. 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.

dahfizz 6y ago

Where I work doesn't delete branches, because there is no reason to. Git branches have essentially zero overhead and deleting them is just extra complexity in the CI toolchain. Deleting branches also deletes context in some scenarios. When dealing with an old codebase its nice to be able to checkout the exact version of the code at some point without having to dig through the log to get hashes and then dealing with a detached head. 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.

richardwhiuk 6y ago
If you are doing squash merges, git branches have a cost.
- dahfizz 6y ago
  A git branch is literally a file with a commit hash in it. It's conceptually a pointer to a commit. Creating, destroying, and maintaining a branch has all the overhead of a ~40 byte file. 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.
rovr138 6y ago
> Git branches have essentially zero overhead Based on the article linked here, they do.
- dahfizz 6y ago
  > 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. 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.

hn_throwaway_99 6y ago

Because they use a monorepo. With monorepos at large companies the individual git repositories will be much larger and contain a ton more branches than if you have a repository-per-project model.

est 6y ago

monorepo culture.