In Github, I have my own fork of GitHub - Slicer/Slicer: Multi-platform, free open source software for visualization and image computing.. Now I want my fork to be synced, i.e.
git fetch upstream and
git merge upstream/master. But merging fails because of the standard commit message Merge remote-tracking branch ‘upstream/master’.
./Utilities/SetupForDevelopment.sh created a git hook to verify that my commit messages are
Am I doing things wrong? Should I use ENH: Merge remote-tracking branch ‘upstream/master’ in for my local repository? I haven’t collaborated much on Github, so I’m unsure how the workflow should be if I want to contribute.
Since in the upstream project we only accept these two types of merge, commit messages always starts with the expected prefix.
If you would like your fork to be synced, consider doing the following instead:
git fetch upstream
git checkout master
git reset --hard upstream/master
git push origin master
I understand that
upstream commits should start with one of Slicer’s commit prefixes. I guess I had wrong workflow. I had been working on a local branch (let’s call it
local-branch), and since
upstream/master evolved at the same time, I thought I should merge
local-branch as explained here. But this caused my problem.
How are you doing when working on a fix/feature on your computer and then later adding it to
upstream/master? Are you doing local rebasing to keep your repository up to date?
We don’t let merge commits to in the repository because it makes the history very complicated and obscures actual changes in the code. Therefore all commits must flow Slicer coding conventions.
What I do is “fetch and rebase” instead of “fetch and merge” when getting updates from upstream (and before creating a pull request).
Then @lassoan’s post should be an answer to this question. Thank you.
Let say you started working on your
local-branch for some feature you want to implement (and later push this feature to
upstream/master). For larger work you may have intermediate commits to
local-branch to keep your work structured (and backed up your work if you push to your
origin). And when you are ready, these intermediate commits can be collapsed into 1 commit having a Slicer-friendly commit message by
git rebase -i. Do you use Slicer-friendly commit messages for your temporary, intermediate commits?
Yes, because the SetupForDevelopment script installs precommit hook that enforces this (and other coding style rules, such as no space at the end of line, maximum line length, etc.).