| 267 | == Getting up-to-speed with the official repository == |
| 268 | |
| 269 | If you have done local changes and added your own commits on top of a git branch, you might at some point want to submit these patches to the mailing list. Or you might just want to test these patches on the latest stuff from the official upstream git repository. The best way to do this is to rebase your branch against the latest changes in the official repositories. This operation is often referred to as "rebasing against upstream". |
| 270 | |
| 271 | First we want to get a fresh update from the official upstream repository. If you used ''git clone'' against one of the official repositories, downloading the latest stuff is done like this: |
| 272 | {{{ |
| 273 | git fetch origin |
| 274 | }}} |
| 275 | |
| 276 | The name ''origin'' is a name of the default repository used when you did the ''git clone'' operation. To see which remote repositories you have configured, you can use this command: |
| 277 | {{{ |
| 278 | git remote -v |
| 279 | }}} |
| 280 | This reports the ''alias'' and the URL for the repository. If the upstream tree is not named ''origin'', you need to replace that with the appropriate git remote ''alias''. |
| 281 | |
| 282 | When you have done the ''git fetch'', you have only downloaded the latest stuff into your copy of the remote repository. No files in your checked-out git branch has been modified yet. So to really apply those changes to your own branch, make sure that you have a clean git tree with no modified files (use ''git status'' to see the status of your currently checked out branch). Then run this command: |
| 283 | {{{ |
| 284 | git rebase origin |
| 285 | }}} |
| 286 | This will first rewind the git branch you are working on, temporarily taking out all your local changes. Then it will add all the modifications done in the remote tree. When that is done, it will apply all your local changes on top of the latest remote branch. If you want to rebase against a particular upstream branch, you do this by also mentioning the branch name: |
| 287 | {{{ |
| 288 | git rebase origin/master |
| 289 | }}} |
| 290 | |
| 291 | It might be that there are some conflicts when doing such rebases. Sometimes it is not so easily for git to understand which version you want to use, your local changes or the upstream version. In these cases, ''git rebase'' will stop and ask for your help. You need to use ''git status'' or ''git diff'' to see which files have issues, and edit each of them manually - removing the code which is not supposed to be there. Then you use ''git add <file(s)>'' to indicate you are done with the files. If ''git status'' now does not list any modified files, then you need to use ''git rebase --skip'' - as the patch is not relevant any more (the upstream tree have already applied these changes) - otherwise you must run ''git rebase --continue''. |
| 292 | |
| 293 | Sometimes there are a lot of conflicts, and this job takes a little while. Other times, there are no conflicts and this ''git rebase'' operation is done in just a few minutes. For massive conflicts, it might be worth checking out ''git mergetool''. This also needs a separate tool, and ''meld'' is one such tool which can be used. |
| 294 | |
| 295 | If you are worried about messing up such rebases, just checkout a test branch and try it there first. Then you'll see how it goes without messing up anything else. |
| 296 | |
| 297 | When ''git status'' shows a clean status ("working directory clean") or just lists files not committed to your branch, then you have successfully rebased your tree to the latest upstream branch. |
| 298 | |