On Tue, Apr 23, 2013 at 3:25 PM, Ian Stakenvicius <a...@gentoo.org> wrote: > Alternatively, we could enforce repoman checks on any commit or push > operation in master, and leave branches to their own devices. Of > course, I haven't seen (or looked for, tbh) how tree development will > be implemented/suggested to be done in git so I've no idea what role > branches might play..
Keep in mind that the following are all roughly equivalent in the world of git: 1. The master branch on anything other than the copy of the repository hosted by infra. 2. Some other named branch anywhere. 3. An overlay. Just because you're committing to master doesn't mean that anybody will ever see it. As far as how things will go - this seems very much TBD. There have been various random thoughts on this list, and in IRC discussions. My two cents: 1. For most routine work, just do it all in master, rebasing commits, so that in the end it looks just like the current CVS (well, assuming CVS had cross-file atomic commits). 2. For big projects, do the work in an overlay first. Then for staging purposes consider a short-term branch in the main repository with frequent rebasing during any QA checks, then do one big fast-forward-merge at the end. That lets you do big atomic tree-wide changes without blocking commits, and having the final merge in a single commit (think KDE stabilization, big eclass changes, etc). We already have overlays, so I'm not sure we want to end up with lots of long-term branches in the main portage repository. All of this is of course talking about the portage tree. More traditional software development projects like portage (the software), eudev, etc should of course use more traditional use of git. Rich
