polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Fwd: Immediate change to git
Date Tue, 03 Nov 2015 23:48:48 GMT
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.


---------- Forwarded message ----------
From: David Nalley <david@gnsa.us>
Date: Wed, Nov 4, 2015 at 4:40 AM
Subject: Immediate change to git
To: David Nalley <david@gnsa.us>

Hi folks,

After the many emails you may have seen around Git, I am writing yet

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


Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message