Upcoming forced reset of masrter branch on Raze

Here, developers communicate stuff that does not go onto the main News section or the front page of the site.
[Dev Blog] [Development Builds] [Git Change Log] [GZDoom Github Repo]

Moderator: GZDoom Developers

User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48326
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Upcoming forced reset of masrter branch on Raze

Post by Graf Zahl »

I will do a force push on Raze's master to eliminate a serious issue with the recent work on the data types. This sits far too deep to remove by other means.
If you work with the repo, please be aware of the necessary steps to adjust your local repo.
User avatar
Rachael
Admin
Posts: 13085
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Upcoming forced reset of masrter branch on Raze

Post by Rachael »

Simplest way to do that:

Code: Select all

git fetch origin
git checkout -B master origin/master
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48326
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Upcoming forced reset of masrter branch on Raze

Post by Graf Zahl »

In case someone is wondering what happened, here's the story.

While testing other things this afternoon I found out that in Blood one door rotated to the wrong side. It turned out that some triggers in the game make an explicit distinction between positive and negative angles - but one recent change was to transition angle storage to a BAM type which has no concept of the same angle being both positive and negative (i.e. -90° is the same as +270°), but the game needs to make the distinction. That entire change sat more than 100 commits deep and selectively rolling back the bad parts was plain and simply impossible. It's easier to recreate from a clean base.
User avatar
Apeirogon
Posts: 1603
Joined: Mon Jun 12, 2017 12:57 am

Re: Upcoming forced reset of masrter branch on Raze

Post by Apeirogon »

Out of curiosity, how often it (reset master/dev to some really old commit) happens in 'enterprise' development?
User avatar
Rachael
Admin
Posts: 13085
Joined: Tue Jan 13, 2004 1:31 pm
Preferred Pronouns: She/Her

Re: Upcoming forced reset of masrter branch on Raze

Post by Rachael »

Probably a lot more than regular hobby development, but it depends on the IT team of that particular corporation. Some corporations do set policies that force pushes are forbidden which leads to an extremely messy commit stream but at least it's much more easily auditable.

There are people who are definitely avowedly against this kind of practice, especially for larger projects, but I am not going to try and say who is right and who is wrong.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48326
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Upcoming forced reset of masrter branch on Raze

Post by Graf Zahl »

At my workplace only one maintainer is allowed to do force pushes on the master branch and they are restricted to address serious issues that would otherwise cause problems if rolled back conventionally.

Of course in cases like this one where the fix would void a major part of the preceding history, not allowing a force push would seriously compromise the repo's integrity. If you got such a large range of commits where you can't bisect anymore will be a huge liability.

That said, I am extremely wary of SCM software where revision history is written in stone once committed. For large scale refactorings it is essential to be able to inject fixes into the commits where they were introduced instead of leaving the intermediate commits between then and now broken. If you got to hunt down the next bug this can quickly make work impossible.

Let's never forget that git was written by someone who had a lot of experience of working on a large scale project and therefore knew precisely what features he needed in this.
dpJudas
 
 
Posts: 2890
Joined: Sat May 28, 2016 1:01 pm

Re: Upcoming forced reset of masrter branch on Raze

Post by dpJudas »

The only places I've ever experienced forced resets of master branches are in GZDoom and Raze. If someone did do something that required a forced reset at work it would immediately lead to meetings about how this could even happen. The thing about forced resets is that everyone else with a branch is fucked over by the reset, so what went wrong that lead to nobody noticing such a fatal mistake before it was too late?

In a professional setting there should have been a work branch for the change discussed here and a test team that should have noticed the issue before it got merged into master. I only cut Raze some slack here because it is a hobby project where resources are so limited that setting up the typical flow isn't doable. To me this isn't about maintaining revision history (couldn't care less), but about which developer pays the price when something go wrong. A reset makes it convenient for the resetter but at the price of everyone else that depended on the stability of the master branch.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 48326
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Upcoming forced reset of masrter branch on Raze

Post by Graf Zahl »

It depends. As long as all people you work with know their way around version control the only situations where a reset is needed is when something got screwed up big time, e.g. that one careless developer merging an unfinished branch and totally screwing up the commit history, or some technical problem.

But well, they happen on occasion. For example, half a year ago we needed to excise a submodule from a project because it constantly caused problems when we had to bisect things. But when that happened, all affected developers were in agreement that it had to be done.

And who says that in the workplace there's sufficient resources to do sufficiently thorough tests on these things that actually find the problem in time? If you operate on a wrong assumption and only much later realize the mistake, all the stability guarantees in the world do not matter anymore. Everything based on the bad code is also broken and convenience becomes a secondary concern.

Return to “Developer Blog”