Closed qwertymodo closed 3 years ago
qwertymodo
commented
3 years ago I just realized that I could sign up my own fork for appveyor as well to test builds (my local build environment wasn't working), so I went ahead and did that, and then ran the merge and fixed the two minor conflicts. Seems to be working great, so I figured I'd PR as well to make your life easier.
devinacker
commented
3 years ago Thanks, I've merged that now. I still need to go over whatever other SGB-related changes I was still planning to make (like fixing up MSU-1 paths for SGB games).
qwertymodo
commented
3 years ago I'd still say go ahead and put any of those changes into master and close the sgbdebug branch, on account of the long time between official releases and the use of appveyor CI builds. That way we don't have to decide if we want to use the branch build for those specific changes or the latest master build for everything else. Branches are great when you're doing a bunch of work that isn't ready to be merged until it's done, not so much for small individual changes.
devinacker
commented
3 years ago Yeah, I wasn't really planning on using that branch any longer since I only intended for it to be used for the initial batch of SGB stuff.
There hasn't been any activity on the sgbdebug branch in a year now, but there are a couple of commits that haven't been merged to master yet. It would be nice to be able to use those couple of commits (especially 24-bit addresses and breakpoint symbols), along with all of the other improvements that have been made in master in that time. And since there isn't a lot of activity on the branch, might as well just delete it. Keeping it around when there isn't active use on it just means that if there is a one-off commit that's SGB related, it'll probably get stuck in that branch for a long time, causing this situation to come up again. If somebody gets an itch to really dig into it again, you can always just create another new branch at that point.