Hi Niclas, and propose to Infra a naming convenction to adopt, so even some standard development branches could have the same settings of master (like our 'develop' branch) ?
Bye 2015-11-04 0:48 GMT+01:00 Niclas Hedhman <[email protected]>: > Guys, > This mail has arrived from Infrastructure VP. > > So, although we are "part of the problem" (i.e. one of the ~50 projects > with 'develop' as the main branch), I am uncertain to what level this > affects us. No-fast-forward is described in our branching model, and I > think we at times remove experimental branches, but not sure. > > Anyway, in case there is any reason this blocking is impacting us, please > bring it up here, and we'll take it to infrastructure once we can formulate > the need. > > Cheers > Niclas > > ---------- Forwarded message ---------- > From: David Nalley <[email protected]> > Date: Wed, Nov 4, 2015 at 4:40 AM > Subject: Immediate change to git > To: David Nalley <[email protected]> > > > Hi folks, > > After the many emails you may have seen around Git, I am writing yet > another. > > To date, on our git repos, we've only 'protected' master, trunk, and > release branches and tags. This has left other branches open to > rewriting, force pushes, and branch deletion. > > Recently, we've discovered that many projects (just under 50) have one > or more repos that are using something other than master or trunk as > their main development branch. In some cases this is a 'develop' > branch in others it's more like $project_version which leaves those > branches open to deletion, rewriting, etc. > > So today, we're taking an interim step of disabling non-fast-forward > pushes and branch deletion across all of our git repos. I emphasize > interim, as it's a stop-gap measure to get us back to the level of > protection we've set expectations for. I know that this will be > disruptive to many folks' way of operating in their git environment, > so we are hoping to make this interim solution short lived. If your > project has immediate needs that you find are blocked by this, please > do reach out to the Infrastructure team, and we will work to make sure > we can help with a timely workaround for those specific cases. > > The longer term solution to this issue may be a policy decision or it > might be a technical solution. I sadly don't know what that solution > will be. We are going to be discussing this on the public > infrastructure-dev mailing list, and I invite you to join us in that > discussion. > > --David > > > > -- > Niclas Hedhman, Software Developer > http://zest.apache.org - New Energy for Java
