The-perfect-Window-Maker-patch.txt

   1 ____________
   2 Introduction
   3 ------------
   4
   5 These notes are meant to help you in the process of making and submitting
   6 patches to the git repository of wmaker-crm.
   7
   8 It assumes you have 'git' correctly installed and you have set the most
   9 basic configuration options via 'git config'. See the end of this file
  10 for an example .gitconfig.
  11
  12 To clone the wmaker-crm repository you can do:
  13
  14 git clone git://repo.or.cz/wmaker-crm.git
  15
  16 You should note that the development occur in the #next branch, and
  17 patches are backported to #master when considered ok. So, you probably
  18 want to switch to #next branch, if not already done:
  19
  20 git checkout next
  21
  22 __________________________
  23 Producing a patch with git
  24 --------------------------
  25
  26 You have the wmaker source and you want to write a patch in order to fix
  27 a bug or improve something. A possible workflow is the following.
  28
  29 # Optional: Create a new branch (to be safe in case you screw up)
  30 git checkout -b fixbug
  31
  32 Now you fix the bug...
  33
  34 # Check what you did, review etc
  35 git diff
  36
  37 # if it looks good, commit your changes
  38 git commit -a
  39
  40 Git will open the editor set in your .gitconfig and you'll have to write a
  41 commit message. Writing a good message is as important as the source code
  42 modifications you've just made! See "Writing the commit log" for advice.
  43
  44 # Prepare the patch to submit to the mailing-list.
  45 # (use HEAD~2 if you want patches for the last 2 commits etc)
  46 git format-patch HEAD~1
  47
  48 # If you have created your own branch, and want all your commits created
  49 # after the #next branch, you can use:
  50 git format-patch next
  51
  52 ______________________
  53 Writing the commit log
  54 ----------------------
  55
  56 You had a motivation to write your patch, you studied the sources and you
  57 found a way to do what you wanted to do. This whole process takes time and
  58 other people will not want to invest that time to rediscover what you've
  59 already found.
  60
  61 So the main reason for the commit message is to explain to other people what
  62 you did, _why_ and _how_. And you must assume that the person you must explain
  63 these things to will not be as familiar with the code you just modified as you
  64 are right after writing the patch -- and that includes yourself in a year or
  65 so. Be verbose in all the steps below.
  66
  67 The good commit log will start with the reason for writing the patch.
  68
  69 For example, if you use wmaker in some way and you expect that X happens but
  70 you get Y, you should say that very clearly. Sometimes that's enough for other
  71 more experienced people to know how to solve your issue. They will be able to
  72 judge your patch better if they know what you wanted to do -- sometimes there
  73 can be a better way to fix it.
  74
  75 Then you should explain why the wmaker source leads to Y and not to X.
  76
  77 Technicall stuff can be expected at this point, e.g. "upon doing xyz in function
  78 foobar(), wmaker sets the variable foo to 'y' instead of setting it to 'x', and
  79 that will lead to blabla happening in function foobar_squared()...".
  80
  81 And finally you explain how you fixed it.
  82
  83 "You have to set foo to 'x', because then when the function foobar_squared() is
  84 called it will do X instead of Y because..."
  85
  86 At this point other people will have a clear understanding of what you did with
  87 minimal effort. And that leads to better patch reviews.
  88
  89 Furthermore, the above reasons should also tell you that you must not do
  90 more than one thing in the same patch. Again:
  91
  92        "Each patch must do one thing and one thing only."
  93
  94 If your patch does too much of unrelated stuff, it makes reviewing a nightmare
  95 and long-term mantainance much worse (think about a patch which introduces a
  96 regression in the middle of many other nice improvements, and now you have to
  97 get rid of the regression without removing the improvements -- 'git revert'
  98 will not help you here).
  99
 100 If you find yourself having troubles to write what you did in the commit
 101 message, perhaps you did too much. In this case you should split your patch
 102 into smaller unrelated pieces and produce a patch series. Unfortunately it's
 103 more work for you, but it's much better for wmaker.
 104
 105 _____________________________________
 106 Sending the patch to the mailing list
 107 -------------------------------------
 108
 109 Send your patches to:
 110
 111 wmaker-dev@lists.windowmaker.org
 112
 113 Please do not send patches to any individual developer unless you have a very
 114 good reason to avoid more people being able to comment (and improve) on your
 115 patches.
 116
 117 The HIGHLY RECOMMENDED way to send a patch is to actually let Git do it for
 118 you, otherwise you may face the problems below. Doing this is really easy:
 119
 120 # Tell git once how to send mails:
 121 #   (of course, replace smtp.example.com with your ISP's)
 122 git config --global sendemail.smtpserver "smtp.example.com"
 123 git config --global sendemail.validate   true
 124 git config sendemail.to "Window Maker Devel <wmaker-dev@lists.windowmaker.org>"
 125
 126 # If you're sending more than 1 patch, you may be interested in having an
 127 # introduction mail for the batch:
 128 git format-patch  --cover-letter  next
 129 vi/emacs/nedit/whatever 0000-cover-letter.patch
 130
 131 # When you're satisfied, ask Git to mail all the patches:
 132 git send-email 00*
 133
 134
 135 If you do not want or cannot let Git send them for you, please note that
 136 sending the patch _properly_ is not as trivial as you may think. Some mail
 137 clients convert TABs to spaces or word wrap long lines automatically, which
 138 will result in your patch being rejected as it will not apply with 'git apply'.
 139
 140 You could send the patch as an attachement to the mail, but this generally
 141 makes it a bit harder to review, and a lot harder to comment on; that's why
 142 the preferred method is inlined patches (like Git does).
 143
 144 Ideally your patch should contain a very good commit message that explains
 145 why you wrote the patch in the first place (see "Writing the commit log").
 146 In this case you can simply send the file(s) created in the 'git format-patch'
 147 step above as the sole content of your email to the mailing list. All your
 148 reasons and explanations will be in the commit log, and your email will look
 149 like:
 150
 151 **********************************
 152 From: someone@someplace
 153 Subject: [PATCH] Fix something
 154
 155 The commit message.
 156
 157 The diff itself.
 158
 159 **********************************
 160
 161 Read the file email-clients.txt in the topdir of the wmaker-crm repository
 162 to be adviced on how to tweak your email client to avoid common pitfalls.
 163
 164 ___________________
 165 Example .gitconfig
 166 -------------------
 167
 168 [user]
 169         name = Erwin Schrodinger
 170         email = schrodinger@gmail.com
 171 [core]
 172         editor = xjed
 173 [status]
 174         showUntrackedFiles = no
 175 [color]
 176         branch = auto
 177         status = auto
 178         diff = auto
 179         ui = auto
 180 [apply]
 181         whitespace = fix
 182
 183
 184
 185
 186