On Tue, 11 Aug 2015 10:26:46 -0400 "Anthony G. Basile" <bluen...@gentoo.org> wrote:
> On 8/11/15 10:19 AM, hasufell wrote: > > On 08/11/2015 04:10 PM, Alexis Ballier wrote: > >> On Tue, 11 Aug 2015 16:01:05 +0200 > >> Michał Górny <mgo...@gentoo.org> wrote: > >> > >>> Dnia 2015-08-11, o godz. 15:52:16 > >>> Patrice Clement <monsie...@gentoo.org> napisał(a): > >>> > >>>> Hi there > >>>> > >>>> According to > >>>> https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Branching_Model, > >>>> "there may be developer-specific, task-specific, project-specific > >>>> branches etc". As far as I understand, it means I can go and > >>>> create my own branch on the main repository and push it and it > >>>> gets spread all over the place. Is that correct? > >>>> > >>>> Could someone explain to me the rationale behind this decision? > >>>> > >>>> Truth to be told, I kinda dislike the fact any developer can do > >>>> this. > >>> As long as it's used with caution, I don't see a problem. > >> Then we should define 'caution' I think :) > >> > >> > I would not say "caution" so much as good judgment. The first > example that came to mind was working with the profiles which crosses > many directories and files. In the past when I did restructuring to > the hardened profiles, I tested by using a branch of the hardened-dev > overlay. It was annoying and I would do a bind mount over > /usr/portage/profiles and had to rebase manually. A test branch of > the the main tree which could get rebased and eventually merged back > would make the workflow so much better. Another example was when we > revitalized the selinux policies. There were hundreds of commits to > be done. A branch here that got merged back would be ideal. you probably did this before it happened, but a solution in the last months could have been to fork gentoo-portage-rsync-mirror, merge it back (or better: rebase onto it) from time to time, and do a squashed PR that you can merge with mgorny's scripts.
