Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
PATCH: document git in Etc/zsh-development-guide
- X-seq: zsh-workers 30901
- From: Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: PATCH: document git in Etc/zsh-development-guide
- Date: Mon, 17 Dec 2012 03:52:15 -0500
- 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=;
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- Mail-followup-to: zsh-workers@xxxxxxx
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
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/
+
Messages sorted by:
Reverse Date,
Date,
Thread,
Author