... | ... | @@ -68,10 +68,16 @@ git rebase --skip # if there are specific commits that you decided to skip, e.g. |
|
|
|
|
|
**PROCESS CHANGE**: We previously (before Oct 2019) put three things in the Changelog: Gitlab issue number, MR number and sha of the commit-id. This uniquely identified the changes, but was annoying and it was difficult to automate (in principle it could be done, but you'd have to develop a script that would use gitlab API to retrieve the MR #). After discussion with several members of the team, I propose to put only issue #. All other details are available using GL web interface.
|
|
|
|
|
|
# Commit logs
|
|
|
# GIT commit logs
|
|
|
|
|
|
**PROCESS CHANGE**: Previously (before Oct 2019) we were supposed to start each commit with `[#Issue number,!MR number]`. This was problematic, because you'd have to look up the MR in gitlab. Also, in cases when you're working on an experiment and you're not sure if there even will be a merge request, you may not have that number at all. As a result, the change proposal is to use `[#Issue number]`. This is something that can be fully automated with a pre-commit hook in gitlab, so you won't need to type it manually.
|
|
|
|
|
|
Commit logs should be descriptive. They are addressed at developers, so code familiarity by the reader is assumed, but please be considerate. "Minor changes" is not a good description. "Fixed typo in addHost()" is better.
|
|
|
|
|
|
Since we sometimes get code from places outside of our control (MRs on gitlab, PRs on github), we cannot assume the [#Issue number] information will always be available.
|
|
|
|
|
|
We don't do commit squashes in general. Sometimes the reviewer pushes fixes or we get commits from contributors (it's essential to get those preserved. Users being able to point to their code and brag about it is one of the reasons they submit patches). If you like, you can squash your own commits.
|
|
|
|
|
|
# Changelog
|
|
|
|
|
|
Changelog entries are requires for every change that is visible by a user. This covers things like new features, bug fixes, changes to build process or documentation. Changelog should be modified on a branch and then merged to master.
|
... | ... | |