This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Moving to git


On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner <bergner@vnet.ibm.com> wrote:
> On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
>> Ramana Radhakrishnan <ramana.gcc@googlemail.com> writes:
>>
>> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely <jwakely.gcc@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
>
>
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]