www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Git, history, protection, and other topics
Date Wed, 04 Nov 2015 14:27:50 GMT
On Wed, Nov 4, 2015 at 7:43 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> On Tue, Nov 3, 2015 at 11:08 PM, David Nalley <david@gnsa.us> wrote:
>> Hi folks,
>>
>> So earlier today I sent an email to PMCs@ indicating that we had
>> turned on disabled fast forward commits and branch/tag deletion across
>> all of the ASF git repositories. [1]
>>
>> The crux of the problem is that infrastructure had set the expectation
>> that certain branches and tags were protected from force pushes or
>> branch/tag deletion.
>>
>> It was recently discovered that a large number of our projects were
>> doing their main branch of development outside of these protected
>> branches, and not using the release branch and tag scheme that would
>> leave them protected.  Some, were using branches with names like
>> 'develop' while others had $project_foo.
>>
>> As a short-term, interim step to allow us to meet the expectation that
>> the main we blocked fast-forward pushes and branch/tag deletion until
>> we can figure out the best way to adequately address the situation.
>>
>> I don't know whether or not the situation is best addressed via policy
>> or technical means, but the discussion here is designed to discover
>> what that should look like, so that we can move past the admittedly
>> blunt, and likely disruptive measure that we introduced today.
>>
>> So; let the discussions begin.
>
> It would be helpful to start with some goals and/or rationale behind
> the current policy.
>
> I'll start with the assumption that "rewrite history" sounds scary.
> I'm going to make the case the term "rewrite history" isn't accurate.
>
> To start with, a git repository is a set of objects.  We will focus on
> commit objects.  Commits are identified by a hash of both content and
> metadata.  Change anything, and you have a new object with a new hash.
>   Push a new commit and you have both the old object and new object in
> the repository.

It's true that you have both old and new objects - but in the case of
inadvertent changes that result in orphaned objects, or change the way
'history looks' (I'll use that term instead of 'rewrite history' since
as you note, it's not entirely accurate) how does one unpick all of
the changes to the way history looks and get that back to an original
state? This is a very real problem I've seen in other projects - a
well meaning developer uses --force and has the ability to disrupt the
view of history, and short of force pushing again (leaving even more
orphaned objects) it's hard reset the view of the repo to the way it
was.

--David

Mime
View raw message