On 03/25/2010 07:51 PM, David ?Bombe? Roden wrote: >> On the other hand, while network-wise it would be more decentralised, >> work-wise it would be more centralised: Code would not go in unless I (or >> another trusted core dev) merged it into the main repository. > > That process is called ?reviewing? and replaces all the ?-official? > repositories. The reviewed code should not be in its own repository, it > should > merely be a branch. Whether it?s a branch called something like ?stable? that > lags behind master or whether ?master? is the reviewed branch and we only > work > in ?next? or ?pu? (?proposed updates,? stolen from git.git) is entirely up to > us.
just to throw a stick into the spokes (or something) i'd like to offer an argument against changing the current setup. the git data model is that commits are immutable global absolute objects, and branches track a thread of commits. you can import the data of any git branch into any git repository and it will be treated as the same data with the same history, independently of the repository that the branch is stored in. however, repositories grant *access* to branches. if we move to the "distributed" model (mis-term IMO) we will effectively be removing a shared branch that a lot of people can commit to. i think this is a bad thing. sometimes you have random one-off commits that don't really belong in a specific branch, and a shared pool branch is the best place to commit it. for this reason i think the current setup is fine; people can start personal branches if they need or want to (and i think this should be seen as the norm). perhaps we should discourage use of the shared "staging" branch, but i don't want to lose it altogether. again, i want to stress that repositories grant *access to branches*, they do not hold data in themselves. X
