Differences

This shows you the differences between two versions of the page.

--- developers:git:specificities_git_abinit [2021/10/05 07:00] – [How to set up a "hotfix" branch to be merged in trunk/release-x.y ?] Xavier Gonze
+++ developers:git:specificities_git_abinit [2024/09/02 14:20] (current) – Maryam Azizi
@@ Line 1: / Line 1: @@
+<WRAP important>**IMPORTANT WARNING**\\ **<color #ed1c24>This Page is obsolete.</color>** Please refer to www.abinit.org!</WRAP>
 ====== git(lab) : ABINIT specificities ======
@@ Line 30: / Line 32: @@
 \\
 After some modifications, using the git commands (e.g. git add, git commit ...), you can push on the gitlab server thanks to : \\
-<color blue>git push </color>\\
-[ or\\
 <color blue>git push --tags  </color>     <color red>( double-dash before tags )</color>\\
-if tags have been introduced...]\\
+\\
 In order for the modifications to be merged in the trunk, a merge request has to be issued, as described later.\\
 \\
@@ Line 74: / Line 74: @@
 For a <color magenta>release-*</color> branch to be **on-track**, not only a specific commit must be contained in the past history of the branch, but also the commit that starts the next development version **cannot** be present. Only one among the <color magenta>release-*</color> branches is **on-track** at any time.
-As an example, suppose we were on ABINIT v9.0.0, and want to start preparing a release 9.0.1 (for release) and a new v9.1.0 (for development)   :
+As an example, suppose we were on ABINIT v9.9.3, and want to start preparing a release 9.10.1 (for release) and a new v9.11.0 (for development)   :
-  * a branch entitled <color magenta>release-9.0</color> will be forked from the <color magenta>develop</color> branch ;
+  * a branch entitled <color magenta>release-9.10</color> will be forked from the <color magenta>develop</color> branch ;
-  * after this branching, the first commit in the <color magenta>release-9.0</color> branch will be tagged start-9.0, while the first commit in the <color magenta>develop</color> is the commit d51ce822
+  * after this branching, suppose the first commit in the <color magenta>release-9.10</color> branch is 1d5efe42, while the first commit in the <color magenta>develop</color> is the commit 34dbe7f2d
-  * for a <color magenta>develop</color> branch to be considered **on-track** (and eligible for a merge request), the commit d51ce822 must be present ;
+  * for a <color magenta>develop</color> branch to be considered **on-track** (and eligible for a merge request), the commit 34dbe7f2d must be present ;
-  * for a <color magenta>release-9.0</color> branch to be considered **on-track** (and eligible for a merge request), the commit tagged start-9.0 must be present, while it will be forbidden to contain the commit d51ce822 .
+  * for a <color magenta>release-9.10</color> branch to be considered **on-track** (and eligible for a merge request), the commit 1d5efe42 must be present, while it will be forbidden to contain the commit 34dbe7f2d .
-In complement to the start of a X.Y.Z version being tagged as "start-X.Y.Z",
+In complement to the start of a X.Y.Z version for release being tagged as "start-X.Y.Z",
-the commit that ends some X.Y.Z version of ABINIT will be tagged "X.Y.Z".
+the commit that ends some X.Y.Z version for release will be tagged "X.Y.Z".
@@ Line 117: / Line 117: @@
 Then, in order to synchronize, in a first step, issue :
-   git fetch trunk
+   git fetch --tags trunk
 then, if the develop branch is to be updated, supposing it is checked out, merge the trunk/develop in your develop :
@@ Line 123: / Line 123: @@
    git merge remotes/trunk/develop
-You can combine the last two commands in one as:
-   git pull trunk develop
 ===== How to set up a "hotfix" branch to be merged in trunk/release-x.y ? =====
-If you have a hotfix, a new branch has to be created. To fix the ideas, let's suppose you want to communicate a bug fix to ABINITv9.6, you have to issue :
+If you have a hotfix, a new branch has to be created. To fix the ideas, let's suppose you want to communicate a bug fix to ABINITv9.8, you have to issue :
-   git branch release-9.6 start-9.6.2    (this creates the branch release-9.6 from the start-9.6.1 tag)
+   git branch release-9.8 start-9.8.0    (this creates the branch release-9.8 from the start-9.8.0 tag)
-   git checkout release-9.6
+   git checkout release-9.8
-   git merge remotes/trunk/release-9.6
+   git merge remotes/trunk/release-9.8
-   git push -u origin release-9.6
+   git push -u origin release-9.8 --tags
-That's it ! You can now make modifications in your release-9.6, then issue a merge request to the trunk/release-9.6 .
+That's it ! You can now make modifications in your release-9.8, then issue a merge request to the trunk/release-9.8 .
 ===== Additional info: how to not mess with your branches ? ... show-branch ... =====