Upcoming forced reset of masrter branch on Raze

[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.

[Rachael]

Simplest way to do that:

Code: Select all

git fetch origin
git checkout -B master origin/master

[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.

[Apeirogon]

Out of curiosity, how often it (reset master/dev to some really old commit) happens in 'enterprise' development?

[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.

[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]

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.

[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.

[Graf Zahl]

I just did another force push on Raze's master.

Over the last weeks I've been adding a converted ZScript version of the internal CON code but ultimately decided not to use this due to technical problems with making it all work.
I'll be making this code available as a separate download to build upon but it makes very little sense to actually use it for the stock actors - and due to its origin I'd rather not have it in the commit history.