From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11181 invoked by alias); 13 Dec 2012 13:04:52 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30877 Received: (qmail 17561 invoked from network); 13 Dec 2012 13:04:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_NONE, T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL,UNPARSEABLE_RELAY autolearn=no version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at yahoo.co.uk does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1355403533; bh=//cHS5HIWpDepWw1O7vS0NB/NUCx5whChHwNdBBltKA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:In-reply-to:From:References:To:Subject:MIME-Version:Content-Type:Content-ID:Date:Message-ID; b=lRr3IlXtGCuqQqxCAEEXkf5DLu77gsg/Cx1/BU1vpsfugCTXIc33HjiYnc7no3pQrIIzXd1AULN7G41XeurziMecay2sFvkV1jub4UkBUVqr9u9oVWmluJY5qxWe01Sa3BKRnVX3FlzXsqQ5Td3GmbU2uc73QwAnfcS4xF82Y2k= X-Yahoo-Newman-Id: 647608.19867.bm@smtp111.mail.ukl.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9DnY5e0VM1niCGjFwJQwW2PtbzV5XRnibw_rkBY3YWkOMxr eIhthArfO0ifXbbDp1izAWnSKQMXVaETOvbK254KaIjV8kB_jj.y_BAmQ7O0 W4dhZwuLkkPRsK6bNbgeAdio_Fb7SVBbi7SNeQdUpFpg3qbEP4SWicJAhZBT 7cL0Pssp8CBuUu9R2oXhHbAU71dPmI08dbY846JQ9jkdNyouWtju9z1pZy71 aVleedvqd8jVBV_LG5vnTWYiq_70Vv3IqtiKvtknqEqqJoX38T2oscOtV6KC KTMH7DnXxxF2AQPdeZFEUH6xIn4EKViQoBI4exTT7Gg3FTn68lGabsWha8iu ugw.B3JaG5aFm4Cv51St6T9lNmjU5VUvdKUb1enipEIcQdcxTktqh0n7IiHs MkzDsHuELgG.rNyAnHEaTCVpCMueNkooLO2SgRUsW X-Yahoo-SMTP: opAkk_CswBAce_kJ3nIPlH80cJI- In-reply-to: <121212105719.ZM28299@torch.brasslantern.com> From: Oliver Kiddle References: <20121204225059.GA9935@redoubt.spodhuis.org> <26711.1354667636@thecus.kiddle.eu> <20121205031447.GA26262@redoubt.spodhuis.org> <121205014000.ZM22819@torch.brasslantern.com> <20121205112647.GA34241@redoubt.spodhuis.org> <20121205195013.64ef36c0@pws-pc.ntlworld.com> <20121207000521.GD20703@pug.qqx.org> <20121207094935.0d9bce83@pwslap01u.europe.root.pri> <4810.1355267148@thecus.kiddle.eu> <87a9tjwuec.fsf@ft.bewatermyfriend.org> <8272.1355333127@thecus.kiddle.eu> <121212105719.ZM28299@torch.brasslantern.com> To: zsh-workers@zsh.org Subject: Re: Access to CVS MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12933.1355403510.1@thecus.kiddle.eu> Date: Thu, 13 Dec 2012 13:58:52 +0100 Message-ID: <12941.1355403532@thecus.kiddle.eu> 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 -------