Fri Jan 25, 2019 1:32 am
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.
Fri Jan 25, 2019 1:36 am
For anyone confused, when Graf pushes the new master, you can use the following command to reset your local branch:
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.
Fri Jan 25, 2019 2:46 am
The new master is now pushed.
Fri Jan 25, 2019 2:48 am
Thanks, it's much cleaner this way, both
Thu Jun 11, 2020 12:46 am
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.
Thu Jun 11, 2020 1:03 am
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.
Thu Jun 11, 2020 1:13 am
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.
Thu Jun 11, 2020 1:13 am
Ah even better, thanks. :)
Thu Jun 11, 2020 5:47 am
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.
Thu Jun 11, 2020 6:00 am
git reset --hard 8af21a13e74d29391692b13af7cd2eb6957e5658
Thu Jun 11, 2020 6:12 am
Or more generically:
git fetch --all
git reset --hard origin/master
Thu Jun 11, 2020 8:23 am
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.
Thu Jun 11, 2020 8:48 am
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.
Thu Jun 11, 2020 2:03 pm
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
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.
Thu Jun 11, 2020 2:30 pm
Rachael wrote: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.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.