about summary refs log tree commit diff
path: root/Etc/zsh-development-guide
diff options
context:
space:
mode:
authorOliver Kiddle <opk@users.sourceforge.net>2012-12-18 23:36:13 +0000
committerOliver Kiddle <opk@users.sourceforge.net>2012-12-18 23:36:13 +0000
commit85d503b91c986a6c24e3e0120ca899863dff1e96 (patch)
tree99bd54658504d171150e2a3816ace82eeeadff5e /Etc/zsh-development-guide
parent4b7bc01fae56368fce684e27b3f466c017fa7e68 (diff)
downloadzsh-85d503b91c986a6c24e3e0120ca899863dff1e96.tar.gz
zsh-85d503b91c986a6c24e3e0120ca899863dff1e96.tar.xz
zsh-85d503b91c986a6c24e3e0120ca899863dff1e96.zip
30877: document git workflow
Diffstat (limited to 'Etc/zsh-development-guide')
-rw-r--r--Etc/zsh-development-guide32
1 files changed, 32 insertions, 0 deletions
diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide
index 9546f284a..e7d73852f 100644
--- a/Etc/zsh-development-guide
+++ b/Etc/zsh-development-guide
@@ -55,6 +55,38 @@ Patches
 * By convention, patches should be sent with a Subject: line starting with
   one of "PATCH:", "[PATCH]" or "[PATCH n/m]" (for a patch series).
 
+Git Workflow
+------------
+ 
+ * To allow changesets to be cross-referenced between the mailing list
+   archives and version control history, commit messages should start with
+   the mailing list sequence number. This number is generated by the list
+   server and inserted as an X-Seq: header field in the e-mail. To add
+   the number, you can use "git commit --amend" to change the commit.
+ 
+ * Do not merge your private feature branches onto the master branch: a
+   linear history without merge commits is simpler to follow (and to
+   bisect). Both "git cherry-pick" and "git merge --ff-only" can be used
+   bring changes over to another branch without a merge commit.
+ 
+ * It is often useful to regularly check in changes while prototyping a
+   solution on a private branch. When finished, it is better to deliver a
+   clean history. For small changes, use "git merge --squash" to get a
+   single changeset for the feature. Where a change can be logically
+   divided into separate changesets use "git rebase -i master" from the
+   feature branch and squash your many intermediate steps into
+   appropriate changesets that each do something meaningful. Post each
+   changeset separately to the mailing list.
+ 
+ * Before pushing your changes to the main zsh repository, you can use
+   "git pull --rebase" to fetch any new updates from the server and
+   rebase your changes on top of them. You can also use "git rebase
+   master" from your feature branches.
+ 
+ * Patches can be prepared for the mailing list with "git format-patch
+   origin/master". To apply patches from a mailing list message, you can
+   use "git am".
+
 Testing
 -------