FPC git: what changed
Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.
| Old | New | Line | |
|---|---|---|---|
| 1 | 1 | ## Git setup | |
| 2 | 2 | ||
| 3 | 3 | ### Git repository location | |
| 4 | 4 | ||
| 5 | 5 | The Git repositories are hosted on Gitlab: | |
| 6 | 6 | ||
| 7 | 7 | FPC compiler, RTL, packages and utils are located here: | |
| 8 | 8 | ||
| 9 | 9 | ||
| 10 | 10 | [<https://gitlab.com/freepascal.org/fpc/source>](https://gitlab.com/freepascal.org/fpc/source) | |
| 11 | 11 | ||
| 12 | 12 | The URL to clone the repository is: | |
| 13 | 13 | ||
| 14 | 14 | ||
| 15 | 15 | [<https://gitlab.com/freepascal.org/fpc/source.git>](https://gitlab.com/freepascal.org/fpc/source.git) | |
| 16 | 16 | ||
| 17 | 17 | git clone https://gitlab.com/freepascal.org/fpc/source.git | |
| 18 | 18 | ||
| 19 | 19 | The Documentation Git repository is here: | |
| 20 | 20 | ||
| 21 | 21 | ||
| 22 | 22 | [<https://gitlab.com/freepascal.org/fpc/documentation>](https://gitlab.com/freepascal.org/fpc/documentation) | |
| 23 | 23 | ||
| 24 | 24 | The URL to clone the documentation repository is: | |
| 25 | 25 | ||
| 26 | 26 | ||
| 27 | 27 | [<https://gitlab.com/freepascal.org/fpc/documentation.git>](https://gitlab.com/freepascal.org/fpc/documentation.git) | |
| 28 | 28 | ||
| 29 | 29 | git clone https://gitlab.com/freepascal.org/fpc/documentation.git | |
| 30 | 30 | ||
| 31 | 31 | The website Git repository is here: | |
| 32 | 32 | ||
| 33 | 33 | ||
| 34 | 34 | [<https://gitlab.com/freepascal.org/fpc/website>](https://gitlab.com/freepascal.org/fpc/website) | |
| 35 | 35 | ||
| 36 | 36 | The URL to clone the website repository is: | |
| 37 | 37 | ||
| 38 | 38 | ||
| 39 | 39 | [<https://gitlab.com/freepascal.org/fpc/website.git>](https://gitlab.com/freepascal.org/fpc/website.git) | |
| 40 | 40 | ||
| 41 | 41 | git clone https://gitlab.com/freepascal.org/fpc/website.git | |
| 42 | 42 | ||
| 43 | 43 | ### Your identity in git | |
| 44 | 44 | ||
| 45 | 45 | In order for your commits to be recognized, please configure your local (or better yet, global) git installation to use the address linked to your gitlab acccount. | |
| 46 | 46 | ||
| 47 | 47 | git config --global user.email your.email.user@youremail.host | |
| 48 | 48 | ||
| 49 | 49 | This will set your email address for all git repositories you use, and will allow the gitlab interface to correctly link commits to users in its HTML interface. | |
| 50 | 50 | ||
| 51 | 51 | If you have multiple gitlab (or even github) accounts, you may prefer to set this email only locally: | |
| 52 | 52 | ||
| 53 | 53 | git config --local user.email your.email.user@youremail.host | |
| 54 | 54 | ||
| 55 | 55 | this command must be execute in a particular repository, and sets the email address for only that repository. | |
| 56 | 56 | ||
| 57 | 57 | ### HTTP access and credentials | |
| 58 | 58 | ||
| 59 | 59 | If you access the repository using HTTPS, by default, git will ask for the username/password. you can tell git to store them permanently, issue the following command: | |
| 60 | 60 | ||
| 61 | 61 | git config --global credential.helper store | |
| 62 | 62 | ||
| 63 | 63 | There are other possibilities for storing this info. More info can be found on | |
| 64 | 64 | ||
| 65 | 65 | ||
| 66 | 66 | [<https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage>](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage) | |
| 67 | 67 | ||
| 68 | 68 | ### Using access tokens | |
| 69 | 69 | ||
| 70 | 70 | You may want to use an access token and HTTPS access, it has some advantages. This is supported by most modern git clients: | |
| 71 | 71 | ||
| 72 | 72 | ||
| 73 | 73 | [<https://knasmueller.net/gitlab-authenticate-using-access-token>](https://knasmueller.net/gitlab-authenticate-using-access-token) | |
| 74 | 74 | ||
| 75 | 75 | and here you can see how to do this on gitlab: | |
| 76 | 76 | ||
| 77 | 77 | ||
| 78 | 78 | [<https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html>](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) | |
| 79 | 79 | ||
| 80 | 80 | The advantage of using an access token is that it can be given limited rights on gitlab, for example only accessing a repository. This also means you can easily enable 2FA for your gitlab account. | |
| 81 | 81 | ||
| 82 | 82 | ### Git mirror on GitHub | |
| 83 | 83 | ||
| 84 | 84 | The GitLab repositories are mirrored on [GitHub](https://github.com/fpc/). Cloning of the sources can be done with the following command | |
| 85 | 85 | ||
| 86 | 86 | git clone https://github.com/fpc/FPCSource.git fpc | |
| 87 | 87 | ||
| 88 | 88 | and for documentation: | |
| 89 | 89 | ||
| 90 | 90 | git clone https://github.com/fpc/FPCDocumentation.git fpcdocs | |
| 91 | 91 | ||
| 92 | - | ||
| 92 | + | In case you want to submit patches (pull requests) it is strongly recommended to use GitLab instead. | |
| 93 | 93 | ||
| 94 | 94 | ## Branching model | |
| 95 | 95 | ||
| 96 | 96 | In a first stage, the branching model as used in Subversion will be used: fixes done in trunk, and later cherry picked to the fixes branch. | |
| 97 | 97 | ||
| 98 | 98 | At a later stage, the branching model may be changed into one of the many git branching schemes. | |
| 99 | 99 | ||
| 100 | 100 | ## Windows Git clients | |
| 101 | 101 | ||
| 102 | 102 | On macOS, Linux & BSD, the git command is installed with the system package manager (you must install XCode command line tools on macOS). On Windows, a separate git client must be installed. There are many available, but the following are popular ones: | |
| 103 | 103 | ||
| 104 | 104 | - Git for windows: a command-line client with a bash shell, so you can copy & paste commands you find on internet: | |
| 105 | 105 | ||
| 106 | 106 | ||
| 107 | 107 | [<https://gitforwindows.org/>](https://gitforwindows.org/) | |
| 108 | 108 | ||
| 109 | 109 | - TortoiseGit integrates with the Windows explorer, much like TortoiseSVN does: | |
| 110 | 110 | ||
| 111 | 111 | ||
| 112 | 112 | [<https://tortoisegit.org/>](https://tortoisegit.org/) | |
| 113 | 113 | ||
| 114 | 114 | if you already have TortoisSVN installed, both can work side-by-side. | |
| 115 | 115 | ||
| 116 | 116 | - Sourcetree is a free client for Windows and macOS: | |
| 117 | 117 | ||
| 118 | 118 | ||
| 119 | 119 | [<https://www.sourcetreeapp.com/>](https://www.sourcetreeapp.com/) | |
| 120 | 120 | ||
| 121 | 121 | It is made by the people from bitbucket. | |
| 122 | 122 | ||
| 123 | 123 | - Smartgit runs on Windows, Linux and macOS: | |
| 124 | 124 | ||
| 125 | 125 | ||
| 126 | 126 | [<https://www.syntevo.com/smartgit/>](https://www.syntevo.com/smartgit/) | |
| 127 | 127 | ||
| 128 | 128 | - The VSCode and Atom editors have git support built in. | |
| 129 | 129 | ||
| 130 | 130 | ## Concepts and SVN to GIT differences | |
| 131 | 131 | ||
| 132 | 132 | A few "good to know" differences: [[FPC git concepts]]. | |
| 133 | 133 | ||
| 134 | 134 | ## Common SVN operations in Git | |
| 135 | 135 | ||
| 136 | 136 | ### Check out | |
| 137 | 137 | ||
| 138 | 138 | To check out a new copy of a repository is called 'cloning' in git. | |
| 139 | 139 | ||
| 140 | 140 | git clone https://gitlab.com/freepascal.org/testconversion | |
| 141 | 141 | ||
| 142 | 142 | As in subversion, you can give it another name: | |
| 143 | 143 | ||
| 144 | 144 | git clone https://gitlab.com/freepascal.org/testconversion myconversion | |
| 145 | 145 | ||
| 146 | 146 | This operation can take a while, the FPC source base is large. | |
| 147 | 147 | ||
| 148 | 148 | ### Update | |
| 149 | 149 | ||
| 150 | 150 | To update your source code with the changes in the remote repository, is called 'pulling' in git: | |
| 151 | 151 | ||
| 152 | 152 | git pull | |
| 153 | 153 | ||
| 154 | 154 | Note that in difference with subversion, git always updates the whole repository. | |
| 155 | 155 | ||
| 156 | 156 | > **Note:** While git will fetch and apply changes to all *remote* branches with this command, of all *local* branches it will only update the one that's currently checked out (see [[FPC git|ls (listing branches)]] for more information about remote/local branches). To update other local branches, you have to [[FPC git|switch]] to them and either execute `git pull` again, or rebase/merge (will be documented once we decide which strategy to use). | |
| 157 | 157 | ||
| 158 | 158 | To keep a commit history which is as linear as possible and avoids merge commits, it is recommended to do a rebase when you pull. | |
| 159 | 159 | ||
| 160 | 160 | git pull --rebase | |
| 161 | 161 | ||
| 162 | 162 | You can make the use of rebase for every pull the default by executing: | |
| 163 | 163 | ||
| 164 | 164 | git config pull.rebase true | |
| 165 | 165 | ||
| 166 | 166 | ### Resolve | |
| 167 | 167 | ||
| 168 | 168 | If you have conflicts in svn after updating or merging, you fix the conflicts and then tell svn everything is fine with the *resolved* command. | |
| 169 | 169 | ||
| 170 | 170 | In git, conflicts generally occur when [[FPC git|merging]] or when applying [[FPC git|shelved/stashed]] changes. | |
| 171 | 171 | ||
| 172 | 172 | When conflicts occur, then | |
| 173 | 173 | ||
| 174 | 174 | 1. Changes to files that are not in conflict, will be [[FPC git|staged]] | |
| 175 | 175 | 2. Changes to files that do conflict will be applied without staging to the working copy (so that a plain [[FPC git|diff]] will only show conflicting changes) | |
| 176 | 176 | ||
| 177 | 177 | To resolve conflicts, | |
| 178 | 178 | ||
| 179 | 179 | 1. If you want to commit the resolved version of the file, mark it as resolved by [[FPC git|staging/adding]] it as well | |
| 180 | 180 | 2. If you want to just get rid of the "both modified" status (= conflicted) without adding the file, use `git reset file` | |
| 181 | 181 | ||
| 182 | 182 | Once all files have been staged or marked as not conflicted, you can commit (only staged files will be committed). | |
| 183 | 183 | ||
| 184 | 184 | ### add (adding new files) | |
| 185 | 185 | ||
| 186 | 186 | Subversion uses the *add* command to add a file to the versioning system. This is no different in git: If you want to add a file, you must add it first, like this: | |
| 187 | 187 | ||
| 188 | 188 | git add newfile.pas | |
| 189 | 189 | ||
| 190 | 190 | You must then (just as in subversion) still commit this newly added file. | |
| 191 | 191 | ||
| 192 | 192 | ### rm (removing files) | |
| 193 | 193 | ||
| 194 | 194 | Subversion uses the *rm* command to remove a file from the versioning system. This is no different in git: | |
| 195 | 195 | ||
| 196 | 196 | git rm nolongerneededfile.pas | |
| 197 | 197 | ||
| 198 | 198 | You must then (just as in subversion) still commit this removed file. | |
| 199 | 199 | ||
| 200 | 200 | ### mv (renaming files) | |
| 201 | 201 | ||
| 202 | 202 | Subversion uses the *mv* command to rename a file in the versioning system. This is no different in git: | |
| 203 | 203 | ||
| 204 | 204 | git mv oldfile.pas newfile.pas | |
| 205 | 205 | ||
| 206 | 206 | You must then (just as in subversion) still commit this change. | |
| 207 | 207 | ||
| 208 | 208 | As in subversion, you can move one or more files to another directory: | |
| 209 | 209 | ||
| 210 | 210 | git mv file1.pas file2.pas somesubdir | |
| 211 | 211 | ||
| 212 | 212 | ### commit | |
| 213 | 213 | ||
| 214 | 214 | If you have made some changes locally and wish to commit them, this is a 2-step process: | |
| 215 | 215 | ||
| 216 | 216 | git add myfile.pas | |
| 217 | 217 | ||
| 218 | 218 | This schedules the file to be committed (called *staging* in git, so the changes are now *staged*). You can add as many files as you want like this. | |
| 219 | 219 | ||
| 220 | 220 | > **Note:** An easy way to remember this is that svn requires the same for newly added files. Git extends this to all changes, because that way you not only can selectively schedule individual new files for the next commit, but also changes to existing files. The opposite of `git add` is `git reset` (**without** the `--hard` parameter!) | |
| 221 | 221 | ||
| 222 | 222 | > **Note:** To see the changes that have been staged/scheduled for commit, use `git diff --cached`. Plain `git diff` will show local changes that are not (yet) staged. | |
| 223 | 223 | ||
| 224 | 224 | When you are ready to commit what you have staged, you can commit: | |
| 225 | 225 | ||
| 226 | 226 | git commit -m '* Some nice comment telling what you did' | |
| 227 | 227 | ||
| 228 | 228 | In fact, if you're in a hurry and know you want to commit a file, you can combine the 2 commands; | |
| 229 | 229 | ||
| 230 | 230 | git commit -m '* Some nice comment telling what you did' myfile.pas | |
| 231 | 231 | ||
| 232 | 232 | If you are really in a hurry, you can commit all changed files in one fell swoop: | |
| 233 | 233 | ||
| 234 | 234 | git commit -m '* Some nice comment telling what you did' -a | |
| 235 | 235 | ||
| 236 | 236 | But it is not really recommended to use this, as it will commit *all* changes in your local copy, not just the ones in the current working directory. | |
| 237 | 237 | ||
| 238 | 238 | At this point, your changes have been saved locally, but have not yet been sent to the remote repository. To do that, you must additionally send the changes to the remote repository. This is called pushing: | |
| 239 | 239 | ||
| 240 | 240 | git push | |
| 241 | 241 | ||
| 242 | 242 | That will send all locally committed changes to the server. Obviously only changes that have not yet been sent previously are sent. | |
| 243 | 243 | ||
| 244 | 244 | ### diff (show changes to working copy) | |
| 245 | 245 | ||
| 246 | 246 | In svn, you can see the changes that have been made but have not yet been committed with *diff*. This is also correct in git: | |
| 247 | 247 | ||
| 248 | 248 | git diff | |
| 249 | 249 | ||
| 250 | 250 | This will show all changes in your working copy ***that are not yet staged*** (scheduled for committing). | |
| 251 | 251 | ||
| 252 | 252 | You can view this for a single file as well: | |
| 253 | 253 | ||
| 254 | 254 | git diff myfile.pas | |
| 255 | 255 | ||
| 256 | 256 | This will show unstaged changes made to your working copy of **myfile.pas**. | |
| 257 | 257 | ||
| 258 | 258 | If you have already staged one or more files (i.e. marked for inclusion in the next commit), the above will not show them in the generated diff. If you wish to see the staged changes (and *only* the staged changed), use the *--cached* command-line option: | |
| 259 | 259 | ||
| 260 | 260 | git diff --cached | |
| 261 | 261 | ||
| 262 | 262 | ### diff (show changes performed in a commit) | |
| 263 | 263 | ||
| 264 | 264 | In svn, you can see the changes that a commit did through `svn diff -c <revision>`. In git, you use the *show* command instead: | |
| 265 | 265 | ||
| 266 | 266 | git show -p <commit_hash_or_branch_or_tag> | |
| 267 | 267 | ||
| 268 | 268 | If you omit the commit hash, the last commit to the current branch will be shown instead. | |
| 269 | 269 | ||
| 270 | 270 | ### log (show commits in a branch) | |
| 271 | 271 | ||
| 272 | 272 | In svn, you can see the commits in a branch with `svn log`. The same works in git: | |
| 273 | 273 | ||
| 274 | 274 | git log | |
| 275 | 275 | ||
| 276 | 276 | This will list the commit hashes (the string that git uses to identify commits, similar to revision numbers in svn) followed by the log messages. If you also want to see which files were changed, use | |
| 277 | 277 | ||
| 278 | 278 | git log --stat | |
| 279 | 279 | ||
| 280 | 280 | ### ls (listing branches) | |
| 281 | 281 | ||
| 282 | 282 | To get a list of branches in Subversion, you use the 'ls' command with a server URL. By convention, all directories under '/branches' are the names of branches. Branches always exist both on the client(s) and server. | |
| 283 | 283 | ||
| 284 | 284 | In git, branches are formalised as part of the version control system: commands deal specifically with branches rather than with paths that are treated as branches. Additionally, git differentiates between **remote branches** (branches that exist in the repository that you cloned, i.e., in this case on the gitlab server), and **local branches** (branches that you created on your machine after cloning). The repository that you cloned is referenced using the alias "origin" by default, and the names of remote branches are prepended by this alias. | |
| 285 | 285 | ||
| 286 | 286 | The list of local branches can be obtained using: | |
| 287 | 287 | ||
| 288 | 288 | git branch | |
| 289 | 289 | ||
| 290 | 290 | By default, the only local branch you will have is `main`, which corresponds to svn trunk. This local branch is automatically created when performing the initial clone operation. | |
| 291 | 291 | ||
| 292 | 292 | The list of remote branches can be obtained using: | |
| 293 | 293 | ||
| 294 | 294 | git branch -r | |
| 295 | 295 | ||
| 296 | 296 | By default, the remote branches are the branches that exist in the repository on the gitlab server, whose alias is "origin". The local `main` branch automatically *tracks* (~ is linked to) the remote `origin/main` branch. Because of this tracking, executing `git pull` resp. `git push` commands while you have your local `main` branch checked out will synchronise the two from resp. to gitlab. See [[FPC git|switch]] on how to create more local branches and how to link them to remote branches. | |
| 297 | 297 | ||
| 298 | 298 | > **Note:** While git always downloads all branches and their commits by default when cloning or pulling and while you can use their content without a network connection, you cannot directly work on remote branches (since they're remote and not local). Instead, you have to create a local branch that "tracks" this remote branch. | |
| 299 | 299 | ||
| 300 | 300 | > **Note:** Do not directly checkout a remote branch. That will put you in a so-called "detached HEAD" state: your working copy will contain the contents from that branch, but you can't commit anything as you can only commit to local branches. You can get out of a "detached HEAD" state by simply checking out another branch. | |
| 301 | 301 | ||
| 302 | 302 | ### copy (creating a branch) | |
| 303 | 303 | ||
| 304 | 304 | To create a branch from the current working directory situation, you can create a branch like this: | |
| 305 | 305 | ||
| 306 | 306 | git branch mybugfix | |
| 307 | 307 | ||
| 308 | 308 | this will create a branch mybugfix from the currently checked out branch at the current commit. But it does not yet make this the active branch. | |
| 309 | 309 | ||
| 310 | 310 | You need to check out the newly made branch first: | |
| 311 | 311 | ||
| 312 | 312 | git checkout mybugfix | |
| 313 | 313 | ||
| 314 | 314 | The two operations can also be combined with one command: | |
| 315 | 315 | ||
| 316 | 316 | git checkout -b mybugfix | |
| 317 | 317 | ||
| 318 | 318 | ### switch (checking out a branch) | |
| 319 | 319 | ||
| 320 | 320 | To switch to an existing *local* branch **mybugfix**, you can use the checkout command: | |
| 321 | 321 | ||
| 322 | 322 | git checkout mybugfix | |
| 323 | 323 | ||
| 324 | 324 | this will check out branch mybugfix. If there are any uncommitted changes which would cause a conflict, git will refuse the checkout. | |
| 325 | 325 | ||
| 326 | 326 | To switch to a *remote* branch \`mybugfix2\`, which does not exist yet locally, you can also use the checkout command: | |
| 327 | 327 | ||
| 328 | 328 | git checkout mybugfix2 | |
| 329 | 329 | ||
| 330 | 330 | this will check out branch mybugfix2 and automatically set it up to track the remote branch. Here again, if there are any uncommitted changes which would cause a conflict, git will refuse the checkout. | |
| 331 | 331 | ||
| 332 | 332 | Note that if the branch does not exist remotely, this will simply create a new branch locally. It is better to be explicit: | |
| 333 | 333 | ||
| 334 | 334 | git checkout -b mybugfix2 --track origin/mybugfix2 | |
| 335 | 335 | ||
| 336 | 336 | If you created a branch locally which does not yet exist on the server, made some modifications, and you wish to push this branch to the server, you must tell this to git when pushing: | |
| 337 | 337 | ||
| 338 | 338 | git push -u origin/mybugfix mybugfix | |
| 339 | 339 | ||
| 340 | 340 | the **-u origin/mybugfix** tells git all it needs to know to connect the local with the remote branch. | |
| 341 | 341 | ||
| 342 | 342 | ### revert | |
| 343 | 343 | ||
| 344 | 344 | #### Revert the entire working tree | |
| 345 | 345 | ||
| 346 | 346 | If you have made some changes locally and wish to undo them, you can do a *hard reset* in git: | |
| 347 | 347 | ||
| 348 | 348 | git reset --hard | |
| 349 | 349 | ||
| 350 | 350 | This will undo any changes you made in the entire checkout, including any [[FPC git|staged changes]]. | |
| 351 | 351 | ||
| 352 | 352 | #### Revert changes to specific files/directories | |
| 353 | 353 | ||
| 354 | 354 | You cannot undo changes to individual files with `git reset --hard`. Instead, use | |
| 355 | 355 | ||
| 356 | 356 | git checkout <pathspec> | |
| 357 | 357 | ||
| 358 | 358 | `pathspec` can be any combination of files and directories. Note that if the files had [[FPC git|staged changes]], this command will restore the staged version rather than the last committed version. | |
| 359 | 359 | ||
| 360 | 360 | > **Note:** At first sight, the git `checkout` command replaces an arbitrary collection of svn commands. The reason is that its operation is defined as "update the files in my working tree to match the specified staged/committed version of the files". So switching to a branch corresponds to getting the version of the files from that branch, while reverting corresponds to the latest version of the files from the current branch. | |
| 361 | 361 | ||
| 362 | 362 | ### merge (merging the changes in 2 branches) | |
| 363 | 363 | ||
| 364 | 364 | To merge changes in 2 branches, you use the *merge* command. If we want to merge the changes in *mybugfix* to *fixes* then we do: | |
| 365 | 365 | ||
| 366 | 366 | git checkout fixes | |
| 367 | 367 | git merge mybugfix | |
| 368 | 368 | ||
| 369 | 369 | ### blame (check who made modifications) | |
| 370 | 370 | ||
| 371 | 371 | To see who changes what line (and in what commit) svn offers you the 'blame' command. The same command exists in git. | |
| 372 | 372 | ||
| 373 | 373 | git blame yourfile.pas | |
| 374 | 374 | ||
| 375 | 375 | ### status (check status of files) | |
| 376 | 376 | ||
| 377 | 377 | To see whether there are any changed files in your working repository, svn offers the 'status' command. The same command exists in git. | |
| 378 | 378 | ||
| 379 | 379 | git status | |
| 380 | 380 | ||
| 381 | 381 | will present you with all changed, staged and new files in the repository. | |
| 382 | 382 | ||
| 383 | 383 | If you want only the status of files below a certain directory, you can specify the name of the directory. So to get the changes in the current working directory (or below) that would be: | |
| 384 | 384 | ||
| 385 | 385 | git status . | |
| 386 | 386 | ||
| 387 | 387 | will present you with all changed, staged and new files in the current directory. This is the default behaviour of svn. | |
| 388 | 388 | ||
| 389 | 389 | ### shelve (temporarily undo changes) | |
| 390 | 390 | ||
| 391 | 391 | Subversion has an (experimental) feature that allows to temporarily set aside changes to your working copy : shelve. This feature exists since a long time in git and is called stash: | |
| 392 | 392 | ||
| 393 | 393 | git stash | |
| 394 | 394 | ||
| 395 | 395 | will set aside any changes to the working copy, and restore the working copy to the state it would be in if you did a 'git pull' (or svn update). | |
| 396 | 396 | ||
| 397 | 397 | To reapply the changes you set aside to the working copy, and to remove them from the list of stashes at the same time, you can execute the following command: | |
| 398 | 398 | ||
| 399 | 399 | git stash pop | |
| 400 | 400 | ||
| 401 | 401 | If any conflicts occur, you can | |
| 402 | 402 | ||
| 403 | 403 | - resolve them, or | |
| 404 | 404 | - use [[FPC git|git reset --hard]] to revert all files again | |
| 405 | 405 | ||
| 406 | 406 | In either case, the stash will not be touched when conflicts occurred while applying it. If you still with to remove it, you can do so with | |
| 407 | 407 | ||
| 408 | 408 | git stash drop | |
| 409 | 409 | ||
| 410 | 410 | ### info (get working dir and server info) | |
| 411 | 411 | ||
| 412 | 412 | In subversion, you can get information about the current working directory and remote server configuration using *svn info*. Since git is a distributed system, no direct equivalent of the info command exists: there is no single server, and the revision number as known in subversion does not exist. | |
| 413 | 413 | ||
| 414 | 414 | The following script attempts to display similar information as the *svn info* command: | |
| 415 | 415 | ||
| 416 | 416 | ``` bash | |
| 417 | 417 | #!/bin/bash | |
| 418 | 418 | ||
| 419 | 419 | # author: Duane Johnson | |
| 420 | 420 | # email: duane.johnson@gmail.com | |
| 421 | 421 | # date: 2008 Jun 12 | |
| 422 | 422 | # license: MIT | |
| 423 | 423 | # | |
| 424 | 424 | # Based on discussion at http://kerneltrap.org/mailarchive/git/2007/11/12/406496 | |
| 425 | 425 | ||
| 426 | 426 | pushd . >/dev/null | |
| 427 | 427 | ||
| 428 | 428 | # Find base of git directory | |
| 429 | 429 | while [ ! -d .git ] && [ ! `pwd` = "/" ]; do cd ..; done | |
| 430 | 430 | ||
| 431 | 431 | # Show various information about this git directory | |
| 432 | 432 | if [ -d .git ]; then | |
| 433 | 433 | echo "== Remote URL: `git remote -v`" | |
| 434 | 434 | ||
| 435 | 435 | echo "== Remote Branches: " | |
| 436 | 436 | git branch -r | |
| 437 | 437 | echo | |
| 438 | 438 | ||
| 439 | 439 | echo "== Local Branches:" | |
| 440 | 440 | git branch | |
| 441 | 441 | echo | |
| 442 | 442 | ||
| 443 | 443 | echo "== Configuration (.git/config)" | |
| 444 | 444 | cat .git/config | |
| 445 | 445 | echo | |
| 446 | 446 | ||
| 447 | 447 | echo "== Most Recent Commit" | |
| 448 | 448 | git --no-pager log -n1 | |
| 449 | 449 | echo | |
| 450 | 450 | ||
| 451 | 451 | echo "Type 'git log' for more commits, or 'git show' for full commit details." | |
| 452 | 452 | else | |
| 453 | 453 | echo "Not a git repository." | |
| 454 | 454 | fi | |
| 455 | 455 | ||
| 456 | 456 | popd >/dev/null | |
| 457 | 457 | ``` | |
| 458 | 458 | ||
| 459 | 459 | Note that this script will also work in the Windows environment if you have the windows git client installed, because it comes with a minimal unix environment. | |
| 460 | 460 | ||
| 461 | 461 | ### bisect'ing | |
| 462 | 462 | ||
| 463 | 463 | When it is known that for example "make cycle" worked for a certain revision but it is broken with the current head of main, one can do a manual "binary search" to find the broken revision. With git, this can be done fully automatically using the git command `bisect`: | |
| 464 | 464 | ||
| 465 | 465 | # change into a directory with a fpc git repository | |
| 466 | 466 | git bisect start # tell git that we start bisecting | |
| 467 | 467 | git bisect bad # mark the currently checkout commit as bad | |
| 468 | 468 | git checkout 12345678 # checkout a commit you know that it is good | |
| 469 | 469 | git bisect good # tell git that at this commit everything is good | |
| 470 | 470 | ||
| 471 | 471 | During this command, git checks out the commit it wants to know if it is good or bad. In case of a broken "make cycle" one can run this now and tell git by "git bisect good" or "git bisect bad" what the status of the commit is. Then git will automatically checkout the next commit to test. After several tests, git will tell which commit that one is which broke "make cycle". As this is a tedious task, the search can be also automated (Unix shell): | |
| 472 | 472 | ||
| 473 | 473 | git bisect run sh -c 'cd $PWD/compiler && make cycle' | |
| 474 | 474 | ||
| 475 | 475 | git runs the passed command and depending on the result value, the commit will be marked as good (0) or bad (1 to 127, 255 tells git to abort search). git continues to run the command till it finds the commit which breaks things. | |
| 476 | 476 | ||
| 477 | 477 | ### file properties (EOL handling etc.) | |
| 478 | 478 | ||
| 479 | 479 | Subversion allows you to set some properties on files. There are 'reserved' properties that svn itself uses, for example to handle EOL handling and file type. Because git operates on diffs and not on files, no similar concept exists. | |
| 480 | 480 | ||
| 481 | 481 | However, git does allow you to set global or local attributes for classes of files. These are in the *.gitattributes* file. That file should be located in the root of your repository, and can contain some attributes. For example: | |
| 482 | 482 | ||
| 483 | 483 | * text=auto | |
| 484 | 484 | *.txt text | |
| 485 | 485 | *.vcproj text eol=crlf | |
| 486 | 486 | *.sh text eol=lf | |
| 487 | 487 | *.jpg -text | |
| 488 | 488 | ||
| 489 | 489 | This is a regular file which you can (and must) add with *git add* so it is saved for all users. | |
| 490 | 490 | ||
| 491 | 491 | ### cherry picking | |
| 492 | 492 | ||
| 493 | 493 | To copy one commit from branch to another, cherry picking can be used, checkout the branch where the commit shall be added and execute: | |
| 494 | 494 | ||
| 495 | 495 | git cherry-pick -x <hash of commit> | |
| 496 | 496 | ||
| 497 | 497 | If this operation causes a conflict, fix it and continue the operation with: | |
| 498 | 498 | ||
| 499 | 499 | git cherry-pick --continue | |
| 500 | 500 | ||
| 501 | 501 | To track which commits are cherry picked, make sure to always use the option `-x`. This appends a small note to the commit message containing the hash of the cherry-picked commit. | |
| 502 | 502 | ||
| 503 | 503 | In case you want to abort the cherry picking e.g. because of too many conflicts, execute | |
| 504 | 504 | ||
| 505 | 505 | git cherry-pick --abort | |
| 506 | 506 | ||
| 507 | 507 | ### Managing the FPC fixes branch | |
| 508 | 508 | ||
| 509 | 509 | So far, FPC uses a developement model which is sometimes called the "ghetto development model". Patches battle out in the main branch if they are good and if they are good, they are ported to the fixes branch from which releases are created. This development model is not naturally supported by git but can be implemented based on cherry-picking. To make tracking of cherry picks easier, `git cherry-pick` must be called with `-x`. Furthermore, only one commit at once may be cherry-pick. | |
| 510 | 510 | ||
| 511 | 511 | Example: | |
| 512 | 512 | ||
| 513 | 513 | ``` bash | |
| 514 | 514 | # change to the top-level of a clone of the FPC Source repository | |
| 515 | 515 | ||
| 516 | 516 | git checkout fixes_3_2 # switch to/checkout out the fixes branches, if you did not do so before | |
| 517 | 517 | git pull # ensure fixes_3_2 is up-to-date | |
| 518 | 518 | git cherry-pick -x 12345678 # 12345678 is the hash (can be a short or full hash) of the commit to be cherry picked to fixes | |
| 519 | 519 | git push # push the change to the remote repository | |
| 520 | 520 | ``` | |
| 521 | 521 | ||
| 522 | 522 | For conflict resolution, see section about cherry picking. | |
| 523 | 523 | ||
| 524 | 524 | To make things a little bit more easy, to get more information in case of conflits and avoid to forget `-x`, use a script `gcp` like: | |
| 525 | 525 | ||
| 526 | 526 | ``` bash | |
| 527 | 527 | #!/usr/bin/env bash | |
| 528 | 528 | git show --name-only $1 | |
| 529 | 529 | git cherry-pick -x $1 || exit 255 | |
| 530 | 530 | ``` | |
| 531 | 531 | ||
| 532 | 532 | > **Note:** Always cherry pick to fixes with -x for tracking and cherry pick only one commit at once. | |
| 533 | 533 | ||
| 534 | 534 | To figure out which hashes are eliglibe (i.e. not yet cherry picked) for cherry picking, use a script like <https://gitlab.com/freepascal.org/fpc/merging/-/blob/main/findeligible> This script is comparable complicated as it takes also merges from svn times into account. A regularily updated list of eliglible commits can be found at: <https://gitlab.com/freepascal.org/fpc/merging/-/blob/main/eligible.log?expanded=true&viewer=simple> | |
| 535 | 535 | ||
| 536 | 536 | #### Mass cherry picking | |
| 537 | 537 | ||
| 538 | 538 | If you have a list of commits identified by their hashes in a file, they can be cherry picked using the script `gcp` from above like: | |
| 539 | 539 | ||
| 540 | 540 | ``` bash | |
| 541 | 541 | xargs -n 1 gcp < filewithhashes | |
| 542 | 542 | ``` | |
| 543 | 543 | ||
| 544 | 544 | Using the script from above is important because xargs only stops if the called program returns 255. So in case of a cherry pick conflict, the command aborts, one can fix the conflict, remove the already cherry picked commits from `filewithwith` and continue. | |
| 545 | 545 | ||
| 546 | 546 | A file with svn revisions can be converted easily to a list of hashes by something like: | |
| 547 | 547 | ||
| 548 | 548 | ``` bash | |
| 549 | 549 | cat filewithrevs | xargs -n 1 git log --grep='trunk@{}' --format='%H' > filewithhashes | |
| 550 | 550 | ``` | |
| 551 | 551 | ||
| 552 | 552 | #### Submitting a request to merge/cherry-pick a certain commit to fixes | |
| 553 | 553 | ||
| 554 | 554 | Using Gitlab allows to have a defined procedure to merge or actually cherry-pick a certain commit from main(/trunk) to fixes. | |
| 555 | 555 | ||
| 556 | 556 | 1. Login to Gitlab | |
| 557 | 557 | 2. Open the commit in Gitlab | |
| 558 | 558 | 3. Click the Options button at the upper right corner and select Cherry-pick | |
| 559 | 559 | 4. Choose the latest fixes branch (fixes_3_2 at the time of writing) in the "Pick into branch" field | |
| 560 | 560 | 5. Click Cherry-pick, if the commit cannot be cherry-picked due to textual conflicts, you get an error in this step. Possible solutions are: | |
| 561 | 561 | 1. Find the commit which needs to be cherry-picked before the current one to get proper textual merging and submit this cherry-pick request first | |
| 562 | 562 | 2. Cherry-pick the commit in a local clone of the respository and submit a merge request against this newly created commit. | |
| 563 | 563 | 6. Do no change anything on the next page, just click Create merge request | |
| 564 | 564 | ||
| 565 | 565 | ## Submitting merge requests | |
| 566 | 566 | ||
| 567 | 567 | A big advantage of a distributed version control system is that you can have your own private repository. So you can fully version your work without any access to the pristine repository and when you are ready, you can submit a so-called merge request (MR) to get your work into the official repository. | |
| 568 | 568 | ||
| 569 | 569 | The workflow is as follows: | |
| 570 | 570 | ||
| 571 | 571 | 1. Login to GitLab | |
| 572 | 572 | 2. Go to the repository of the project you want to work on, e.g. FPC Source: <https://gitlab.com/freepascal.org/fpc/source> | |
| 573 | 573 | 3. Click Fork at the upper right corner and choose the settings as you like in the following dialog, then click Fork at the bottom. GitLab creates now a full copy of the chosen repository. | |
| 574 | 574 | 4. Clone the newly create repository to your machine by getting the URL from the Clone button at the upper right corner of the respository's page on GitLab (e.g. `git clone `[`https://gitlab.com/YourUsername/fpcsource.git`](https://gitlab.com/YourUsername/fpcsource.git)). | |
| 575 | 575 | 5. Create a new branch for your work: `git checkout -b myfeature` | |
| 576 | 576 | 6. Now do your work: change, commit, change, etc. | |
| 577 | 577 | 7. When you are ready, push your branch with `git push origin` into your private repository on GitLab. At this point GitLab shows you already a link how to submit the changes as a merge request to the official/pristine repository. Click the link and follow the instructions. | |
| 578 | 578 | 8. If you want to automatically keep your fork up to date with the pristine repository, go to Settings -\> Repository -\> Mirroring repositories and fill in the required fields as described in the [GitLab docs](https://docs.gitlab.com/ee/user/project/repository/mirror/index.html). | |
| 579 | 579 | ||
| 580 | 580 | Of course, it is possible work with more than one remote repository in a local one. I.e. push/pull changes from and to your own private one and pull from the official repository. This would go to far for this wiki, have a look at <https://git-scm.com/book/en/v2/Git-Basics-Working-with-Remotes> instead. | |
| 581 | 581 | ||
| 582 | 582 | --- | |
| 583 | 583 | *From the Free Pascal wiki, page "FPC git", as it stood on 2022-03-06 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 584 | 584 | Category: Version Control |