Skip to content

Git Tips & Tricks

Patrick Seewald edited this page Dec 10, 2018 · 6 revisions

Git Rebase

Basics

We want a linear Git history, which is why you can't have any merge commits in Pull Request. To keep you branch up-to-date (or get rid of the merge commit), use Git rebase instead of merge.

To update your branch or your master - assuming origin points to your fork and upstream to the offical CP2K repository, add the --rebase parameter to the git pull call:

$ git pull --rebase upstream master

If you have pushed this branch already to your fork on a remote side (GitHub most likely), you then have to use force-push since the commits changed:

$ git push --force

Resolving conflicts

When resolving conflicts during a Git Rebase you have to keep in mind that when Git refers to changes as theirs or remote, this is actually what you have in the branch you are rebasing.

So, when running a mergetool using

$ git mergetool

the right pane (the file is called *.REMOTE) is how the file looked after the current commit before the rebase, the left how it currently looks in master and the middle pane shows you its new content after this rebase.

If you know that you want to take all your changes (for example because you've created the file in this branch but you ran the prettifier in a previous commit in this rebase, therefore breaking your own commits), you can do:

$ git checkout --theirs -- path/to/your/file

Likewise: if you know you want to discard your changes to a specific file in this commit, use --ours instead.

Updating after introduction of Git Submodules

With commit aacf780 we are using Git Submodules to track the separately developed DBCSR. This requires a one-time upgrade of your current clones and forks:

$ cd cp2k  # change to your CP2K clone

Update each of your branches using the following:

$ git pull --rebase upstream master  # update the currently checked out branch to the current CP2K/master
$ git submodule update --init  # update and initialize the submodule support. After this, the folder `exts/dbcsr` should be populated

If you have Git >= 2.14, run the following after upgrading your branches in each of your clones to make sure that Git updates the dbcsr submodule automatically when switching branches or pulling updates.

$ git config submodule.recurse true

This is a local (per local clone) setting and will never be reflected on your GitHub fork. You can make it global on your local machine (and therefore have to run it only once) by adding the --global flag:

$ git config --global submodule.recurse true

If you have Git < 2.14, you will have to run the following from now on everytime after switching branches or pulling updates to ensure that the DBCSR submodule points to the correct version:

$ git submodule update
You can’t perform that action at this time.