How the git repo is organized

The OHRRPGCE source code is in a git repo. This page is meant to describe how we have organized things.

We are in the middle of a long-overdue migration to use git instead of svn as our main upstream repo. Any mentions of "Subversion" or "svn" are obsolete, and we are in the process of cleaning them up. Thank you for your patience!

We are still re-organizing things right now, so some of this may be subject to change.

The repo is located at https://github.com/ohrrpgce/ohrrpgce/

Branches

Our default branch is wip

We do not use branches named main or master

Stable releases are on branches named for the silly codename of each release. You can see them listed on the History of Release Dates

There are also a few obsolete legacy branches such as "tools" and "web" from before we moved those into their own separate repos.

Merging

Bob the Hamster (talk) prefers the rebase model of merging new features and fixes into the wip branch. It keeps the wip branch history extremely simple.

This typically means that if I have a feature branch, before I merge it to wip, I like to rebase it on top of wip. This moves all my commits on the feature branch to the end, so they come after whatever other new things may have been merged to wip while I was working. This means when I merge my feature branch back to wip, the merge will be a linear fast-forward merge.

This also means that if I want to keep using the same feature branch for more changes, I need to rebase it again on top of wip after the previous set of changes were merged. This mild inconvenience is worth it to me for the simple linear history. This might possibly mean that I am an old-fashioned fuddy-duddy. Please kindly get off my lawn. ;)

There is no reason why we can't merge branches in the traditional git merge way. My rebase preferences are not a requirement, and I will not refuse pull requests just because they don't do it. (I will however, refuse pull requests if they obviously haven't been kept caught up with upstream wip well enough for me to believe they will actually work)

Versioning of the wip branch

The wip branch has a serial version number that must be incremented. It was originally based on the subversion upstream revision number. The last one was 14308. Now that git is the main upstream, the revision number is calculated by counting the commits since the last svn revision.

This can be done with the following one-liner:

echo $(( $(git rev-list --count 18b01b80f..HEAD) + 14308 ))

There is also a convenience-script that does the same thing. (It also has comments that explain how it works)

misc/revision_number.sh

This number is used internally by the OHRRPGCE editor and player and can be recorded in rpg data files. It is used as part of some of the logic for when to display upgrade notifications, and when to show compatibility warnings. (Don't confuse this with Incrementing the RPG format version number which is used in slightly similar ways, but is a totally different number!)

Upstream & Pull Requests

Only the lead developers James and Ralph currently have write access to the upstream repo.

If you want to send pull requests, you can fork your own copy of the repo.

Make sure your feature branch is reasonably up-to-date with the upstream repo

# syncing your feature branch
git fetch upstream
git checkout myfeaturebranch
git merge upstream/wip
# This is when you would resolve merge conflicts if they exists

Then after you have pushed your feature branch to your own fork repo, you can make a "compare across forks" pull request and James or Ralph can review it.

Future changes AFTER the subversion migration

This is the section for listing stuff we would like to do differently, but we don't want it to distract from the scope of the svn -> git migration work.

• It would be nice to have a stable tag pointing to the latest stable release