Re: Access to CVS

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

Bart wrote:
> I would greatly appreciate it if someone would generate a summary of the
> conclusions of this discussion with all the various "recommended" steps
> that one would perform, so that it could be added as a sort of how-to in
> Etc/zsh-development-guide.

Ok, how does this look?

The zsh patch archive doesn't exist any more does it?

Having prepared this with git, I realise that "git format-patch" doesn't
really fit with the way we're used to working. It produces full e-mail
headers with the expectation that the commit message forms the actual
body of the e-mail. It also uses [PATCH] instead of PATCH: though that's
minor. As with this message, we often include a patch in a reply. Should
we recommend something else?

> And then for everyone to agree with at least the general outline of that
> that summary, before we make the switch -- which I further think should
> wait until 5.0.1 has gone out.

Yes, waiting for 5.0.1 makes sense.

Oliver

diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide
index db78f94..cf7ff1c 100644
--- a/Etc/zsh-development-guide
+++ b/Etc/zsh-development-guide
@@ -32,6 +32,7 @@ Patches
 -------
 
 * Send all patches to the mailing list rather than directly to me.
+  Use a Subject: line starting with "PATCH:".
 
 * Send only context diffs "diff -c oldfile newfile" or unified diffs
   "diff -u oldfile newfile".  They are much easier to read and
@@ -39,7 +40,7 @@ Patches
   intelligently.  Please make sure the filenames in the diff header
   are relative to the top-level directory of the zsh distribution; for
   example, it should say "Src/init.c" rather than "init.c" or
-  "zsh/Src/init.c".
+  "zsh/Src/init.c". Alternatively, use "git format-patch".
 
 * Please put only one bug fix or feature enhancement in a single patch and
   only one patch per mail message.  This helps me to multiplex the many
@@ -52,9 +53,37 @@ Patches
 * Please test your patch and make sure it applies cleanly. It takes
   considerably more time to manually merge a patch into the baseline code.
 
-* There is now a zsh patch archive.  To have your patches appear in the
-  archive, send them to the mailing list with a Subject: line starting
-  with "PATCH:".
+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
 -------