Ian Stakenvicius: > > I'm not that worried about the big (multi-package) commits, as it does > make sense we're going to have difficulty and lots of potential > conflicts there, but aren't we going to run into this issue just with > multiple people committing separate single-package commits at the same > time?? >
Yes. If that becomes a major problem, then we have to say goodbye to the central repository workflow, because we either * allow inconsistency and broken states as we do now with CVS (and rely on QA to run a repoman tinderbox and reverse-fixing broken crap) * require devs to rebase+merge and rerun repoman 10+ times in order to get a single commit pushed It is already pretty gross and broken to have ~200 people have direct push access to a single repository. However, having ~150 commits per day I don't think this commit rate is high enough to deadlock push access. git pull --rebase=preserve && repoman full && git push origin master or something similar. This can even be implemented a bit more sanely within repoman or another script, but I don't think we need that yet. It's also possible that projects start accumulating changes in branches or even their own repositories to minimize the amount of pushes to master. The merge-rate will be something that has to be dynamically figured out and will improve tree quality. We shouldn't try to map our CVS workflow 1:1 to git, so there have to be changes in workflow. The optimum would be to have a real review workflow enforced with only a handful of people having direct push access, but I doubt this will work in our current community and mindset. However, such a review workflow can dynamically evolve, because it's git after all! If that happens, we can just make it a policy at some point or even implement it on infra-level.
