Commit c347405a authored by Elvis Angelaccio's avatar Elvis Angelaccio

GIT_SILENT Update HACKING file

Better documentation about how to do a merge.
parent 41b25127
......@@ -26,30 +26,67 @@ First of all, you should do your work in a separate branch, and each commit
should be as atomic as possible. This way, if you are asked to make changes to
them, the rest of your work is not disturbed and you can easily rebase.
New features are committed to the `master' branch, respecting KDE's Release
New features are committed to the `master` branch, respecting KDE's Release
Schedule policies. This means the soft and hard freeze periods must be
respected, as well as the string freeze policy.
Bug fixes are committed to the latest stable branch (for example, Applications/16.04),
which is then merged into the `master' branch. Do *NOT* cherry-pick commits
Bug fixes are committed to the latest stable branch (for example, `Applications/16.04`),
which is then merged into the `master` branch. Do *NOT* cherry-pick commits
into multiple branches! It makes following history unnecessarily harder for no
reason.
To merge the stable branch into `master', the following steps can be followed:
### How to merge stable in master
To merge the stable branch into `master`, the following steps can be followed:
$ git checkout Applications/16.04 # Whatever the stable branch is
$ # hack, hack, hack
$ # commit
$ git checkout master
$ git merge --log --edit -s recursive -Xours KDE/4.8
$ git merge --log --edit -s recursive -Xours Applications/16.04
Do not worry if unrelated commits (such as translation ones made by KDE's
translation infrastructure) are also merged: translation commits are
automatically reverted when needed, and other commits being merged should be
bug fixes by definition.
The merge command above will try to automatically resolve conflicts by
preferring the version of master. This is usually good, for example a conflict
often happens on the `KDE_APPLICATIONS_VERSION_XXX` variables in the root
CMakeLists.txt file. On the stable branch you will find something like:
set (KDE_APPLICATIONS_VERSION_MAJOR "16")
set (KDE_APPLICATIONS_VERSION_MINOR "04")
set (KDE_APPLICATIONS_VERSION_MICRO "02")
while on master you will find something like:
set (KDE_APPLICATIONS_VERSION_MAJOR "16")
set (KDE_APPLICATIONS_VERSION_MINOR "07")
set (KDE_APPLICATIONS_VERSION_MICRO "70")
In this example, the `ours` strategy option will pick the master version,
which is what we want. However, when a more complex conflict happens,
the `ours` option might fail to autoresolve the conflict and might leave
the working tree in a weird state. You should *always* check what the merge
actually did by using (after the merge):
$ git diff origin/HEAD HEAD
If the diff output is not what you expect, you can reset the merge with:
$ git reset --hard origin/HEAD
Then you can do a simple merge which will *not* resolve conflicts:
$ git merge Applications/16.04
and finally resolve all conflicts by hand.
### Pushing your changes
When you are ready to push your commits to the remote repository,
you may need to update your local branch first.
Do *NOT* create unnecessary merge commits with
`git pull', as these commits are completely avoidable and make following
history harder. Instead, you should *rebase* first (git pull --rebase).
`git pull`, as these commits are completely avoidable and make following
history harder. Instead, you should *rebase* first (`git pull --rebase`).
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment