It is OK Look at microsoft/vscode
58,891 commits 360 branches 0 packages 145 releases 1,048 contributors MIT The pr-branches are deleted on merge. The relasease branches foreverever WIP branches are there until merged, or superseded. -----Original Message----- From: Gregory Nutt [mailto:spudan...@gmail.com] Sent: Tuesday, December 24, 2019 12:44 PM To: dev@nuttx.apache.org Subject: Re: Software release life cycle choices could have implications on workflow (was RE: Single Committer) > Git's claim to fame is supposed to be the cheapness of branches. What if > each PR becomes its own branch and then it either: (a) gets worked on, (b) > applied to master, or (c) deleted? I think that would work fine. We need to verify that we can actually change the PR base, but if so that would keep things more independent. Perhaps it could help us with patches where sometimes there are patches that depend on each other or interact with other because they modify the same area of code. Using git to help merge patches would be easier if the patches were on different branches. We would probably need some encoding of branch names to associate them with patches or PRs. Many branches would be awkward on patch sets that consist of a dozen or so individual patches that cannot be squashed together because they have different authors. We get lots of large patch sets from Xiaomi like that. To make things more complex, there is an ordering in which the patches must be apply. A given patch may not apply until a preceding patch by a different author is first merged. The number should not be a big concern. Over time, we will end up with 100's of branches eventually. Each release will probably have to be on a branch. Greg
