Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Tue, Apr 23, 2013 at 3:25 PM, Ian Stakenvicius <axs@g.o> 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