Zsh Mailing List Archive
Messages sorted by:
Re: Access to CVS
> 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
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.
diff --git a/Etc/zsh-development-guide b/Etc/zsh-development-guide
index db78f94..cf7ff1c 100644
@@ -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". 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:".
+* 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".
Messages sorted by: