Git repository: Resetting the Master branch

[Graf Zahl]

People using the git repo to self compile or those using devbuilds may have noticed that the binaries from the master branch have become somewhat unstable.

This was the result of some bad refactoring that turned out harder to fix than expected.
Unfortunately there is no easy solution to fix this code on short notice. It would require a lot of time to straighten things out so in order to get back a stable master branch I decided to roll back the abovementioned refactoring and then reconstruct a new branch, only containing the clean commits.
But due to the extent of the changes - we are talking about 140 commits here from which 50 had to be re-applied this cannot be done without actually resetting master to a different branch in the repo.

This means that everybody working directly with the repo will have to do a rebase of master, once the changeover has been made. I have to apologize for this but the alternative would be a prolonged period of extreme instability that would be detrimental to the project itself.

[Rachael]

For anyone confused, when Graf pushes the new master, you can use the following command to reset your local branch:

Code: Select all

git fetch
git checkout -B master origin/master

Please note that if you have a special multi-repo setup, rename the "master" in that command to your local branch (i.e. gzdoom) and the second "origin/master" to the remote (i.e. gzdoom-remote/master).

If you already did a pull and your local branch is in a conflicted state, you can use "git merge --abort" to terminate the pull and then do the reset as described above.

[Graf Zahl]

The new master is now pushed.

[Nash]

Thanks, it's much cleaner this way, both

[Graf Zahl]

Unfortunately I had to do another master rebase to get the unfinished shadow feature out of there. This should have been committed to a work branch because it shouldn't go active unless there is an implementation for the hardware renderer.

[Nash]

That's fine, I'll work on it off a branch on my fork and be sure the hardware implementation is ready before sending a PR.

[Graf Zahl]

I already made a new branch for it - it should be in the GZDoom repo, just not in master, because I still need that for potential new releases.

[Nash]

Ah even better, thanks. :)

[phantombeta]

Rewriting history for this was very overkill. IMO rewriting history should be reserved for big changes that have to be completely reverted (e.g., the failed first level data rework attempt), not something like this that could've been simply disabled internally without even reverting the commits. Now everyone who has pulled these commits will have to deal with the pain in the ass that fixing their local repo is.

[_mental_]

Code: Select all

git reset --hard 8af21a13e74d29391692b13af7cd2eb6957e5658

[Rachael]

Or more generically:

Code: Select all

git fetch --all
git reset --hard origin/master

[Nash]

I did it with TortoiseGit UI, it was pretty simple too - just right-click on a previous "safe" commit, and "reset master to this (hard)", then I just pull and force push.

[Graf Zahl]

It's really only "hard" when using the command line tools. With any GUI tool it's just resetting the label - one or two clicks with the mouse.
And no, this couldn't have been done without a reset. Every time I did that I had to deal with a mess afterward because the work branch couldn't be merged cleanly anymore.

[Rachael]

It's actually simple to do it with command line tools, without resetting a branch.

First, you find the commit you don't want, then type

Code: Select all

git revert <hash>

- this creates a *new* hash that you will have to remember, push the branch, then create a new one, then simply revert the revert.

This creates a branch that can still be merged, it just has a revert that has been reverted, effectively leaving the actual file system in its original state before the revert, but creating a history that is compatible with a proper merge in the new branch, all without a forced reset.

[Graf Zahl]

that you will have to remember,

That's precisely where the "easy" part ends.
What I like about TortoiseGit is that the commit log is basically a visual editor for the repo, allowing to move branch and tag labels around as you please. It really cannot get any easier. I use this constantly.
The command line is good for simple actions like pushing/pulling/switching branches but as soon as hashes are needed it becomes a chore.