On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner <berg...@vnet.ibm.com> wrote: > On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: >> Ramana Radhakrishnan <ramana....@googlemail.com> writes: >> >> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <jwakely....@gmail.com> >> > wrote: >> >> Teams following a different model could use a separate repo shared by >> >> those developers, not the gcc.gnu.org one. It's much easier to do that >> >> with git. >> > >> > Yes you are right they sure can, but one of the reasons that teams are >> > doing their development on a feature branch is so that they can obtain >> > feedback and collaborate with others in the community. >> >> It is also much easier for others to pull from foreign repositories with >> git, so this isn't a severe downside. > > It may be easy for git to pull from foreign repositories, but it may > be difficult/impossible (policy wise) for some developers from some > companies to be able to write to foreign repositories. At IBM, we > cannot host our own source repositories that others can access. We can > only write to the official source code repositories for the projects > that we have clearance to work in. We currently have an IBM vendor > directory where we have our branches. If we move to git (I'm all for > it), I would hope that those can remain in the official source code > repository.
I don't think I've seen anyone argue against the existence of such branches in the main repository. My query was whether allowing for rebase (rewriting history) in published feature branches was a decision to be left to the branch maintainers or was this going to be a repository wide restriction. It also seems odd to me that trunk follows a (manual) fast-forward / rebase and apply kind of development workflow while feature development branches cannot maintain these in terms of <mainstream>....<feature_patches> without jumping through hoops. regards Ramana > > That said, if the GCC project created an "official" side repository > where branches are stored, we could participate in that. > > Peter > > >
