commit 8ea39d9a7c27ef035f082a383106e0c240295b7d
parent c756cfbac3df258d32b739286f9ca396ac0e6418
Author: Ondrej Grover <ondrej.grover@gmail.com>
Date: Sat, 7 Jun 2014 23:07:25 +0200
add a how to for maintaining patches in git
as an alternative to the hg patch queue tutorial
Diffstat:
1 file changed, 91 insertions(+), 0 deletions(-)
diff --git a/dwm.suckless.org/customisation/patches_in_git.md b/dwm.suckless.org/customisation/patches_in_git.md
@@ -0,0 +1,91 @@
+# How to maintain dwm configuration and customization in git #
+
+Since suckless.org has migrated to git, customizations can now be be
+managed directly in git as an alternative to the
+[patch queue in Mercurial tutorial](http://dwm.suckless.org/customisation/patch_queue).
+
+## The concept ##
+
+By recording changes and applied patches as commits in a special
+branch they can be rebased on top of the master branch when required.
+
+## Cloning the repository ##
+
+You need to have the [Git VCS](http://git-scm.com/) installed first.
+Then clone the upstream repository locally
+
+ git clone git://git.suckless.org/dwm
+
+## Recording customizations ##
+
+Create a special branch where all the customizations will be kept. It
+doesn't matter what the name is, it just needs to be something
+different than `master`.
+
+ git branch my_dwm
+
+Now switch to the new branch. This will do nothing at the moment as
+the branches are the same.
+
+ git checkout my_dwm
+
+Now make your changes. If you want to apply one of the
+[contributed patches](http://dwm.suckless.org/patches/) you can use
+the `git apply` command
+
+ git apply some_patch.diff
+
+Note that many patches make changes `config.def.h` instead of `config.h`. Either
+move those changes also to `config.h`, or add `rm config.h` to the
+`clean` target in the `Makefile`.
+
+Then record the changes as commits
+
+ # tell git to add the changes in the given file(s) to be recorded
+ git add some_file.ext
+ # git will ask you to provide a message describing your changes
+ git commit
+
+### Experimenting with different combinations of customizations ###
+
+If you plan on experimenting with different combinations of
+customizations it might be easier to record the commits in separate
+feature branches by first creating and checking out a branch and then
+recording the changes as commits. Having patches in different branches
+also helps to keep their dependencies transparent by creating branches based
+on other patch branches.
+
+Then merge the selected combination of changes into your branch
+
+ git merge some_feature_branch
+ git merge other_feature_branch
+
+If you some conflicts occur, resolve them and then record the changes
+and commit the result. `git mergetool` can help with resolving the
+conflicts.
+
+## Updating customizations after new release ##
+
+When the time comes to update your customizations to after a new
+release of dwm or when the dwm repository contains a commit fixing
+some bug, you first pull the new upstream changes into the master
+branch
+
+ git checkout master
+ git pull
+
+Then rebase your customization branch on top of the master branch
+
+ git checkout my_dwm
+ git rebase master
+
+In case there are merge conflicts resolve them (possibly with the help
+of `git mergetool`), then record them as resolved and let the rebase
+continue
+
+ git add resolved_file.ext
+ git rebase --continue
+
+If you want to give up, you can always abort the rebase
+
+ git rebase --abort
