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:44:32 GMT
On Wed, Nov 4, 2015 at 9:34 AM, Sam Ruby <rubys@intertwingly.net> wrote:
> On Wed, Nov 4, 2015 at 9:27 AM, David Nalley <david@gnsa.us> wrote:
>> 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.
> To get something back to the original state, use 'git update-ref'
> specifying the name of the reference and the previous commit.
> To do something considerably more complicated, use 'git cherry-pick'
> where you can specify a set of commits that you want to apply.

(I'm a pessimist, forgive me :) )
In my experience, when this goes catastrophically wrong this would be
more difficult; though I think I could see how git-update-ref  could
work to pull that off - though it's equally scary that git-update-ref
can so easily change the view of history. I will play with this some
today and see how well it goes.


View raw message