From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8959 invoked by alias); 17 Dec 2012 08:52:34 -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: 30901 Received: (qmail 12969 invoked from network); 17 Dec 2012 08:52:21 -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=-3.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL, DKIM_SIGNED,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at spodhuis.org does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201210; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=s56B7dFF+C+5q0+7vHJbvtBhL0gmW57UIoC8LsdzzTg=; b=LxreiEksNG0Zd71K5hPFBHjdBZ/3bINyera8M1uDUUOuiciprCcaVRXZ4tcHKxM82DLUWKCysAZ145Zzfh15fuBwvX6isIkU/AByAL3OOQKsp9GUODj6w4wSHywweV6Ea/DU+McPHTS6mg6CVOV81RAHWthOFRnAHZ6U5VjuDeo=; Date: Mon, 17 Dec 2012 03:52:15 -0500 From: Phil Pennock To: zsh-workers@zsh.org Subject: PATCH: document git in Etc/zsh-development-guide Message-ID: <20121217085215.GA87227@redoubt.spodhuis.org> Mail-Followup-To: zsh-workers@zsh.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note that http://www.zsh.org/ appears to be down, and zsh.sunsite.dk does not exist in DNS, but in searching for the "Zsh Patch Archive", I can only find a reference to: http://zsh.sunsite.dk/Patches/ The development guide still says to prefix patch mails with "PATCH:" for the patches to make it into the patch archive. Is this still true, and if so where is the archive? Or should I also change that text to permit "[PATCH]" and "[PATCH n/m]" per git-format-patch? -Phil Index: Etc/zsh-development-guide =================================================================== RCS file: /cvsroot/zsh/zsh/Etc/zsh-development-guide,v retrieving revision 1.23 diff -a -u -p -u -d -r1.23 zsh-development-guide --- Etc/zsh-development-guide 3 Feb 2010 18:36:57 -0000 1.23 +++ Etc/zsh-development-guide 17 Dec 2012 08:46:10 -0000 @@ -841,13 +841,13 @@ Distribution of files --------------------- zsh is distributed in two parts: a "src" distribution containing all -the source files (roughly, but not exactly, corresponding to the CVS +the source files (roughly, but not exactly, corresponding to the git tree), and a "doc" distribution containing some pre-built files from the documentation directory. All the files in the "doc" distribution may be generated from files in the "src" distribution with appropriate freely available tools. -To indicate which files should be distributed, each directory in the CVS +To indicate which files should be distributed, each directory in the git tree includes a file .distfiles that sets any number of a set of Bourne shell (scalar) parameters. The value of the parameter is expanded as a set of standard command line arguments. Basic globbing is allowed in the @@ -862,6 +862,69 @@ The following parameters are currently u distribution. - DISTFILES_NOT is a list of files that will not be included in a - distribution, but that need to be present in the CVS tree. This + distribution, but that need to be present in the git tree. This variable is not used by the zsh build process and is present for the convenience of external checks. + + +Use of Git +---------- + +zsh has migrated from CVS to git for version control. We have so far +kept our workflow unchanged; to wit: + + 1. change is developed and posted to the zsh-workers mailing list + 2. the zsh-workers list management software adds an X-Seq: header + 3. an entry is added to ChangeLog with details, including the X-Seq: + header. + [Open Question: should the first 6 or so characters of the commit + fingerprint be included, so: "* 12345/deadbeef: frobbed the baz" ?] + 4. this is committed to git as a second commit + 5. this is pushed to the master server + +Micro Git Tutorial: + + % $VISUAL file1.c file2.c new-file3.c + % git add new-file3.c + % git commit -a + % git push + + "git commit -a" automatically finds files which are tracked and have + been modified, but doesn't pick up new files; "git add" adds a file to + the index to be part of the next commit, and can be used for new files + or for existing files (commit -a is a shortcut for the latter) + + "git push" assumes that you're on the master branch and the repository + was created by cloning it from some place, with default options. + +Feature branch work: + + % git checkout -b feature_foo + % $VISUAL path/to/files ... + % git commit -a + [lather, rinse, repeat] + % git push origin feature_foo + [ do mailing-list stuff here ] + [ Switch back to master: ] + % git checkout master + [ and get the most recent changes: ] + % git pull + [ make the branch content now be relative to *new* master tip ] + % git checkout feature_foo + % git rebase master + [ then bring in your changes: ] + % git checkout master + % git merge --ff-only feature_foo + % $VISUAL ChangeLog + % git commit -i ChangeLog + % git push + [ Cleanup: ] + % git branch -d feature_foo + % git push origin :feature_foo + +Git further reading: + * git help tutorial + * git help tutorial-2 + * git help gitcore-tutorial + * http://www-cs-students.stanford.edu/~blynn/gitmagic/ +