How to Commit

Preferred practice is to work in a branch in a private fork, and use pull-requests to merge your work into master. Even if you have commit access, using a pull-request helps to avoid some common git mistakes and provides a single point of discussion if there are any issues with your work. Also, pushing to your private fork will build the compiler, run the integration tests, and produce a report letting you know if you've committed any atrocities.

If you have access, you can of course merge your own pull-request, because the purpose of the pull-request is organization, not gatekeeping. If your changes are straightforward, you can merge them immediately, but it is always OK to wait a few days to see if anyone has any comments.

Quick Version

# origin should refer to your private fork
git clone git@github.com/my/cm3.git
git remote add upstream https://github.com/modula3/cm3.git

# create a feature branch for your work
git checkout -b my-branch
git commit

# ensure you've incorporated all upstream work
git fetch upstream
git rebase upstream/master

# push to your private fork
git push --force origin my-branch

Configuration

Some useful git settings:

git config merge.ff only
git config pull.rebase true

---

N.B., The astute reader will no doubt notice that the author does not use pull-requests for most of his work. This unfortunate exception is because most of my work to-date has been in CI/CD and various Github limitations require hard-coded repository names in workflow files. The consequence of hard-coded names is that CI/CD scripts can work in my repository but fail if pulled unmodified into upstream.