5 This documentation assumes the reader is already familiary with using ``git``
6 for managing file revisions.
14 GROMACS development happens on gitlab at https://gitlab.com/gromacs/gromacs.
15 Create a user account at https://gitlab.com/users/sign_in#register-pane or use
16 an exisiting account at gitlab.com. For more information on how to use gitlab have
17 a look at their extensive user documentation at https://docs.gitlab.com/ee/user/index.html.
18 We follow the workflow described in https://docs.gitlab.com/ee/topics/gitlab_flow.html.
20 If you do not already have a GROMACS repository set up, user
21 ``git clone git@gitlab.com:gromacs/gromacs.git`` to obtain the current GROMACS
22 repository from gitlab. Otherwise use
23 ``git remote add gitlab git@gitlab.com:gromacs/gromacs.git``.
25 Using gitlab, new code enters GROMACS by merging git development branches into
28 To automatically detect issues in new code, it is tested within continuous
29 integration (CI) with a large combination of settings.
30 See `gmx-codeformatting` for help meeting and testing the style guidelines.
32 Setting up login credentials with gitlab
33 ----------------------------------------
35 You will need a public ssh key. If you were using Gerrit, you probably
36 already have one and you can ignore the first line::
38 ssh-keygen -t rsa -C "your.email@address.com"
41 Copy the output of the last command, got to gitlab.com, find you user in the
42 right top corner and select settings.
44 Chose SSH keys in the menu on the left and past your key in the text field.
49 The meta-level code design and discussions is organised in issues and visible at
50 https://gitlab.com/gromacs/gromacs/-/issues. Please check if if your issue or a
51 similar issue already exists before creating a new one.
53 Note that all Redmine issues have been transferred to gitlab with the same issue
54 numbers as used in gitlab. However, comments and discussion are now represented
55 by gitlab user @acmnpv - the original authors are found inline at the bottom of
58 Uploading code for review - creating a merge request
59 ----------------------------------------------------
61 Issues are addressed with new code via "merge requests" (MR). Find the current
62 MRs at https://gitlab.com/gromacs/gromacs/-/merge_requests.
63 There are two ways of creating a merge request - either via the gitlab graphical
64 user interface or via the command line.
66 To use the GUI, find the relevant issue or open a new one, then find the
67 "create merge request" button to create a merge request related to that issue in gitlab.
68 The default selection is to mark this a work in progress (WIP) merge-request.
69 We recommend keeping this setting until you are completely satisfied with the
70 code yourself and all tests are passed.
72 Select milestone and assignees to make tracking of the progress easier.
73 Keep the requirements for merging as they are set by default.
75 You can also use ``git push`` on the command line directly and create a merge request
76 following the link that is output on the command line.
78 Your repository should be in sync with the GROMACS repository. To ensure this,
79 use ``git fetch`` to obtain the newest branches, then merge the master branch
80 into your branch with ``git merge master`` while on your branch.
85 Good names: documentation_UpdateDevelopersDocsTOGitLab, nbnxm_MakeNbnxmGPUIntoClass, pme_FEPPMEGPU.
86 Bad names: branch1234, mybranch, test, etc
91 Labels <https://docs.gitlab.com/ee/user/project/labels.html>`__ help developers by allowing additional filtering of issues and merge requests.
93 The GROMACS project `defines many labels <https://gitlab.com/gromacs/gromacs/-/labels>`__.
95 .. Note: labeling guidelines TBD. See https://gitlab.com/gromacs/gromacs/-/issues/3949 and open new issues as appropriate.
99 * Ongoing categorizations to help specify the GROMACS component or development area use the ``#7F8C8D`` color.
100 * Specific features or subproject areas targeting an upcoming release use the ``#8E44AD`` background color.
102 When creating a new label, please provide a short description
103 so that people can understand what the label is intended to convey,
104 and when they should apply it to their own issues or merge requests.
106 .. Best practices and labeling policies can be proposed as changes to this document. See https://gitlab.com/gromacs/gromacs/-/issues/3949
111 Reviewing someone else's uploaded code
112 --------------------------------------
114 The reviewing workflow is the following:
116 #. https://gitlab.com/gromacs/gromacs/-/merge_requests shows all open changes
117 #. A change needs two approvals to go in, of which one approval has to come from
118 a member of either GMX Core or GMX Developers.
119 #. Usually a patch goes through several cycles of voting, commenting and
120 updating before it becomes merged, with votes from the developers indicating
121 if they think that change hat progressed enough to be included.
122 #. A change is submitted for merging and post-submit testing
125 Do not review your own code. The point of the policy is that at least
126 two non-authors have approved, and that the issues are resolved in the
127 opinion of the person who applies an approval before a merge. If you have
128 uploaded a minor fix to someone else's patch, use your judgement in
129 whether to approve yourself.
134 - First and foremost, check correctness to the extent possible;
135 - As portability and performance are the next most important things do check
136 for potential issues;
137 - Check adherence to the :ref:`GROMACS coding standards <style-guidelines>`;
138 - We should try to ensure that commits that implement bugfixes (as
139 well as important features and tasks) get an `issue tracker`_ entry created
140 and linked. The linking is done **automatically** through
141 `special syntax <https://gitlab.com/help/user/markdown#special-gitlab-references>`__
142 - If the commit is a **bugfix**\ :
144 - if present in the `issue tracker`_, it has to contain a valid reference to the
146 - if it's a **major bug**, there has to be a bug report filed in the
147 `issue tracker`_ (with urgent or
148 immediate priority) and referenced appropriately.
150 - If the commit is a **feature/task** implementation:
152 - if it's present in the `issue tracker`_ it
153 has to contain a valid reference to the issue;
154 - If no current issue is currently present and the change
155 would benefit of one for future explanation on why it was
156 added, a new issue should be created.
158 Moving code from gerrit to gitlab
159 =================================
161 Create a local repository that is connected to both Gerrit and Gitlab::
163 git clone git@gitlab.com:gromacs/gromacs.git -o gitlab gromacs-migrate
165 git remote add gerrit ssh://<gerrit-username>@gerrit.gromacs.org/gromacs.git
168 Checkout the current gitlab master::
170 git checkout gitlab/master
172 Go to your commit on https://gerrit.gromacs.org/ , select Download->Cherry-Pick
174 ``git fetch "https://gerrit.gromacs.org/gromacs" refs/changes/XX/YYYY/ZZ && git cherry-pick FETCH_HEAD``
176 Resolve conflicts, if any. If you need to do further changes to your patch,
177 feel free to ammend them at this point. Remove the Gerrit commit-id line from
178 the bottom of the commit message, but keep the issue (ex. redmine) references -
179 they match the gitlab issues.
181 Do not forget to run clang-format script (``admin/clang-format.sh update -f --rev=HEAD^``)
182 and copyright script (``admin/copyright.sh update -f --rev=HEAD^``).
184 When ready, move the patch to a new branch::
186 git branch <branch-name>
188 Make sure to select a unique branch name that it is easy for you to connect to
189 a specific patch. You will need it later to make changes to your merge request.
190 Keep in mind that your branch name is going to be exposed to everyone while
191 your patch is under review. Push the branch to GitLab::
193 git push gitlab <branch-name>
195 Go to https://gitlab.com/gromacs/gromacs and create a merge request.
196 Copy-paste your commit message from Gerrit into the merge request description
197 text box, use the first line as a title. If your branch has only one commit,
198 this will be done automatically. Add "From: https://gerrit.gromacs.org/#/c/gromacs/+/XXXXX/"
199 to the end of your commit message.
200 Select "Delete source branch when merge request is accepted." check-box.
201 Select "Squash commits when merge request is accepted" check-box.
202 Check and that squash commit message is correct. If necessary, update it.
204 If your change in Gerrit depends on another Gerrit change:
206 Make sure that you transfer the parent change to GitLab first.
207 When transferring the child change, specify the parent in the "Merge request dependencies" text field.
208 In GitLab menu, go to Repository -> Compare. Select the branch that correspond
209 to the child change as a Source in the drop-down menu, choose parent change as
210 the Target. Click Compare button and copy the link from the browser address bar.
211 Add "Compare to the parent: https://gitlab.com/gromacs/gromacs/-/compare/PARENT_BRANCH...CHILD_BRANCH"
212 to the description of the merge request. You will have to keep this dependency
213 up to date for the link to work properly. For example, if you update the parent,
214 you will need to merge its branch to the child branch right away.
215 Otherwise your recent updates will show up in comparison.
221 .. rubric:: Q: Are there some other useful git configuration settings?
223 A: If you need to work with
224 branches that have large
225 differences (in particular, if a
226 lot of files have moved), it can
231 git config diff.renamelimit 5000
233 to increase the limit of inexact
234 renames that Git considers. The
235 default value is not sufficient,
236 for example, if you need to do a
237 merge or a cherry-pick from
238 a release branch to master.
240 .. rubric:: Q: How do I use git rebase (also ``git pull --rebase``)?
242 A: Assume you have a local
243 feature branch checked out, that
244 it is based on master, and master
245 has gotten new commits. You can
252 to move your commits on top of
253 the newest commit in master. This
254 will save each commit you did,
255 and replay them on top of master.
256 If any commit results in
257 conflicts, you need to resolve
258 them as usual (including marking
259 them as resolved using git add),
264 git rebase --continue
266 Note that unless you are sure
267 about what you are doing, you
268 should not use any commands that
269 create or delete commits (git
270 commit, or git checkout or git
271 reset without paths). ``git rebase
272 --continue`` will create the commit
273 after conflicts have been
274 resolved, with the original
275 commit message (you will get a
278 If you realize that the conflicts
279 are too messy to resolve (or that
280 you made a mistake that resulted
281 in messy conflicts), you can use
287 to get back into the state you
288 started from (before the
289 original git rebase master
290 invocation). If the rebase is
291 already finished, and you realize
292 you made a mistake, you can get
293 back where you started with
295 log <my-branch>@{1} and/or git
296 reflog <my-branch> to check that
297 this is where you want to go)
301 git reset --hard <my-branch>@{1}
303 .. rubric:: Q: How do I prepare several commits at once?
305 A: Assume I have multiple independent changes in my working tree.
312 to add one independent change at
313 a time to the index. Use
319 to check that the index contains
320 the changes you want. You can
321 then commit this one change:
327 If you want to test that the
328 change works, use to temporarily
329 store away other changes, and do
336 If the testing fails, you can
337 amend your existing commit with
338 ``git commit --amend``. After you are
339 satisfied, you can push the
340 commit for review. If
341 you stashed away your changes and
342 you want the next change to be
343 reviewed independently, do
347 git reset --hard HEAD^
350 (only do this if you pushed the
351 previous change upstream,
352 otherwise it is difficult to get
353 the old changes back!) and repeat
354 until each independent change is
355 in its own commit. If you skip
356 the ``git reset --hard`` step, you
357 can also prepare a local feature
358 branch from your changes.
360 .. rubric:: Q: How do I edit an earlier commit?
362 A: If you want to edit the latest
363 commit, you can simply do the
370 If you want to edit some other
371 commit, and commits after that
372 have not changed the same lines,
373 you can do the changes as usual
378 git commit --fixup <commit>
384 git commit --squash <commit>
386 where <commit> is the commit you
387 want to change (the difference is
388 that ``--fixup`` keeps the original
389 commit message, while ``--squash``
390 allows you to input additional
391 notes and then edit the original
392 commit message during ``git rebase
393 -i``). You can do multiple commits
394 in this way. You can also mix
395 ``--fixup/--squash`` commits with
396 normal commits. When you are
401 git rebase -i --autosquash <base-branch>
403 to merge the ``--fixup/--squash``
404 commits to the commits they
405 amend. See separate question on
406 ``git rebase -i`` on how to choose
409 In this kind of workflow, you
410 should try to avoid to change the
411 same lines in multiple commits
412 (except in ``--fixup/--squash``
413 commits), but if you have already
414 changed some lines and want to
415 edit an earlier commit, you can
420 git rebase -i <base-branch>
422 but you likely need to resolve
423 some conflicts later. See ``git
424 rebase -i`` question later.
426 .. rubric:: Q: How do I split a commit?
428 A: The instructions below apply
429 to splitting the HEAD commit; see
430 above how to use ``git rebase -i`` to
431 get an earlier commit as HEAD to
434 The simplest case is if you want
435 to split a commit A into a chain
436 A'-B-C, where A' is the first new
437 commit, and contains most of the
438 original commit, including the
439 commit message. Then you can do
443 git reset -p HEAD^ [-- <paths>]
446 to selectively remove parts from
447 commit A, but leave them in your
448 working tree. Then you can create
449 one or more commits of the
450 remaining changes as described in
453 If you want to split a commit A
454 into a chain where the original
455 commit message is reused for
456 something else than the first
457 commit (e.g., B-A'-C), then you
464 to remove the HEAD commit, but
465 leave everything in your working
466 tree. Then you can create your
467 commits as described in other
468 tips. When you come to a point
469 where you want to reuse the
470 original commit message, you can
477 to find how to refer to your
478 original commit as ``HEAD@{n}``, and
483 git commit -c HEAD@{n}
485 .. rubric:: Q: How do I use git rebase -i to only edit local commits?
487 A: Assume that you have a local
488 feature branch checked out, this
489 branch has three commits, and
490 that it is based on master.
491 Further, assume that master has
492 gotten a few more commits after
493 you branched off. If you want to
494 use ``git rebase -i`` to edit your
495 feature branch (see above), you
502 followed by a separate
508 The first command allows you to
509 edit your local branch without
510 getting conflicts from changes in
511 master. The latter allows you to
512 resolve those conflicts in a
513 separate rebase run. If you feel
514 brave enough, you can also do
515 both at the same time using