PATCH: document git in Etc/zsh-development-guide

PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

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/
+

Re: PATCH: document git in Etc/zsh-development-guide

[Frank Terbeck]

Phil Pennock wrote:
> 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/

All sunsite.dk links are invalid and should point to sf.net instead:

  http://zsh.sourceforge.net/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?

That would be good.

> +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" ?]

How about generating the ChangeLog before releases instead of updating
it manually? I find that to be an unnecessary manual step, especially
since the same information is just one "git log" or "gitk" away. I wrote
a generation tool a while back, which I linked to a couple of times
already[1].

If I am the only one who thinks that this might be useful, please tell
me, so I can keep my mouth shut about it in the future. :-)


Regards, Frank

[1] http://ft.bewatermyfriend.org/comp/genchangelog.html

Re: PATCH: document git in Etc/zsh-development-guide

[Peter Stephenson]

On Mon, 17 Dec 2012 03:52:15 -0500
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> 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?

I think the patch archive is defunct and the [PATCH] marking, which it
might be useful for clarity (although only to some extent, given
interaction with responses) is therefore largely also defunct.

pws

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-17 at 10:15 +0000, Peter Stephenson wrote:
> I think the patch archive is defunct and the [PATCH] marking, which it
> might be useful for clarity (although only to some extent, given
> interaction with responses) is therefore largely also defunct.

http://zsh.sourceforge.net/Patches/ suggests that the archive lasted
just over two months, 1997 to 1998, and that this bit of the development
guide is now 14 years and 11 months stale.

An ... interesting record?

Second patch shortly (when CVS responds ... I'd forgotten how much
_faster_ git, and even svn, is than CVS).

-Phil

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-17 at 10:59 +0100, Frank Terbeck wrote:
> All sunsite.dk links are invalid and should point to sf.net instead:
> 
>   http://zsh.sourceforge.net/Patches/

Thanks.

> How about generating the ChangeLog before releases instead of updating
> it manually?

My understanding from the previous thread is that we're taking small
steps to make the transition manageable.  Notably, neither of the two
most prolific contributors to zsh (Peter and Bart) uses Git yet.

So we do things the same way they are now.  Once all the developers have
gotten a good feel for how things work with git and have internalised
the new tooling's model, _then_ we might reconsider changes to the
workflow.  For now, we let the tooling support the model that is
working.


Peter, Bart: I was in much the same situation as you are now, when Exim
switched.  At the time, my stance was "I don't care which VCS is used, I
don't think changing VCS solves any fundamental issues with
contribution, I didn't care, but now is a good time to consider our
options" (it was an in-person meetup of the maintainers).  A couple of
people were strongly pro-git, so we went along with that.

I then spent the next couple of months swearing.  There was mutual
support on the mailing-lists as we grappled with the changes.  Our wiki
gained a couple of entries from various folks:
  http://wiki.exim.org/EximGit
  http://wiki.exim.org/SampleWorkFlow

The one thing I'll say now:
 % git config --global user.name "Fred Bloggs"
 % git config --global user.email fred@examle.org

because git commits are immutable once published and you probably want
to get the correct name and address for publication set up.  You can
vary these on a per-repo basis too.

-Phil

Re: PATCH: document git in Etc/zsh-development-guide

[Oliver Kiddle]

Phil Pennock wrote:
> Second patch shortly (when CVS responds ... I'd forgotten how much
> _faster_ git, and even svn, is than CVS).

Note that my proposed patch in 30877, would already remove this section.
It'd make things easier if we don't have conflicting patches prepared
for immediately after the git migration.

Oliver

Re: PATCH: document git in Etc/zsh-development-guide

[Benjamin R. Haskell]

On Mon, 17 Dec 2012, Peter Stephenson wrote:

> On Mon, 17 Dec 2012 03:52:15 -0500
> Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
>> 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?
>
> I think the patch archive is defunct

What about: http://www.zsh.org/mla/patches.shtml ?

That appears to have been updated last on Nov 20, 2012.

-- 
Best,
Ben

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-17 at 09:17 -0500, Benjamin R. Haskell wrote:
> On Mon, 17 Dec 2012, Peter Stephenson wrote:
> > On Mon, 17 Dec 2012 03:52:15 -0500
> > Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> >> Note that http://www.zsh.org/ appears to be down,
> >
> > I think the patch archive is defunct
> 
> What about: http://www.zsh.org/mla/patches.shtml ?
> 
> That appears to have been updated last on Nov 20, 2012.

Still appears down for me.  Connection refused on ports 80 and 443, from
two countries (so not a Geo-IP-based packet filter).

-Phil

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-17 at 14:50 +0100, Oliver Kiddle wrote:
> Phil Pennock wrote:
> > Second patch shortly (when CVS responds ... I'd forgotten how much
> > _faster_ git, and even svn, is than CVS).
> 
> Note that my proposed patch in 30877, would already remove this section.
> It'd make things easier if we don't have conflicting patches prepared
> for immediately after the git migration.

I pushed the changes to CVS after making them, figuring that Peter is
working from a fixed point for the 5.0.1 candidates and can either
branch zsh-development-guide if we wants to elide my changes, or keep
the content, because my understanding is that after 5.0.1 goes out,
we'll be on git, so guidance on how to contribute "as of release 5.0.1"
will require git.

Made more sense to me for the content to be in, so I committed as per
usual, so that instead of endless debate there's something solid in the
repo which can be patched if there's a need.

-Phil

Re: PATCH: document git in Etc/zsh-development-guide

[Benjamin R. Haskell]

On Tue, 18 Dec 2012, Phil Pennock wrote:

> On 2012-12-17 at 09:17 -0500, Benjamin R. Haskell wrote:
>> On Mon, 17 Dec 2012, Peter Stephenson wrote:
>>> On Mon, 17 Dec 2012 03:52:15 -0500
>>> Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
>>>> Note that http://www.zsh.org/ appears to be down,
>>>>
>>>> [trimmed context:]
>>>> but in searching for the "Zsh Patch Archive", I can only find a 
>>>> reference to: http://zsh.sunsite.dk/Patches/
>>>> [/trimmed context]
>>>
>>> I think the patch archive is defunct
>>
>> What about: http://www.zsh.org/mla/patches.shtml ?
>>
>> That appears to have been updated last on Nov 20, 2012.
>
> Still appears down for me.  Connection refused on ports 80 and 443, 
> from two countries (so not a Geo-IP-based packet filter).

www.zsh.org is down for me, too.  I viewed it via Google's cache (It was 
last crawled on Dec 14, with the latest patch as of Dec 5):

http://www.google.com/search?q=cache%3Ahttp%3A%2F%2Fwww.zsh.org%2Fmla%2Fpatches.shtml

My point was just that that's the up-to-date patch archive, AFAIK (not 
the one at the retired zsh.sunsite.dk).  patches.shtml was linked from 
http://www.zsh.org/mla (and it's #1 for the query: zsh patches).

-- 
Best,
Ben

Re: PATCH: document git in Etc/zsh-development-guide

[Peter Stephenson]

On Tue, 18 Dec 2012 04:36:18 -0500
Phil Pennock <zsh-workers+phil.pennock@spodhuis.org> wrote:
> I pushed the changes to CVS after making them, figuring that Peter is
> working from a fixed point for the 5.0.1 candidates and can either
> branch zsh-development-guide if we wants to elide my changes, or keep
> the content, because my understanding is that after 5.0.1 goes out,
> we'll be on git, so guidance on how to contribute "as of release
> 5.0.1" will require git.

There's no branch --- it's a waste of time unless people are actively
developing during the release --- but presumably the latter is true.

pws

zsh.org & patch archive

[Phil Pennock]

On 2012-12-18 at 09:11 -0500, Benjamin R. Haskell wrote:
> www.zsh.org is down for me, too.  I viewed it via Google's cache (It was 
> last crawled on Dec 14, with the latest patch as of Dec 5):
> 
> http://www.google.com/search?q=cache%3Ahttp%3A%2F%2Fwww.zsh.org%2Fmla%2Fpatches.shtml
> 
> My point was just that that's the up-to-date patch archive, AFAIK (not 
> the one at the retired zsh.sunsite.dk).  patches.shtml was linked from 
> http://www.zsh.org/mla (and it's #1 for the query: zsh patches).

So if it is supposed to still exist, who do we talk with or where do we
check out the integration tools, so that we can make sure the patch
archive picks up list mails with the git-format-patch subject prefix
variants ([PATCH] and [PATCH n/m])?

Is this Geoff?

-Phil

Re: zsh.org & patch archive

[Bart Schaefer]

On Dec 18,  3:37pm, Phil Pennock wrote:
}
} So if it is supposed to still exist, who do we talk with or where do we
} check out the integration tools, so that we can make sure the patch
} archive picks up list mails with the git-format-patch subject prefix
} variants ([PATCH] and [PATCH n/m])?

This is reachable again:  http://www.zsh.org/mla/patches.shtml

It appears to pick up anything that looks like a diff, whether the word
"PATCH" appears in the subject or not.  E.g., the patch archive lists

    http://www.zsh.org/cgi-bin/mla/redirect?WORKERNUMBER=30840

} Is this Geoff?

I believe so.

Re: PATCH: document git in Etc/zsh-development-guide

[Oliver Kiddle]

Phil Pennock wrote:
> Made more sense to me for the content to be in, so I committed as per
> usual, so that instead of endless debate there's something solid in the
> repo which can be patched if there's a need.

On that basis, I've committed the change I had proposed too, excepting
those parts that conflict with yours.

Seems we need to revert some of that change, however, given that the
patch archive does still exist. It'd also be nice not to leave the
following question in the actual file:

> +    [Open Question: should the first 6 or so characters of the commit
> +     fingerprint be included, so: "* 12345/deadbeef: frobbed the baz"
> ?]

I think the answer to this is "no" given the chicken and egg problem of
getting the correct hash into the commit log. Having the fingerprint of
the change as posted to the mailing list also seems fairly useless as
the only other place it would persist is in the mailing list archives
and that can be referenced with the number.

I also note the following as part of your steps:
> +  % git push origin feature_foo
...
> +  [ Cleanup: ]
> +  % git push origin :feature_foo

The first command makes the feature branch available so perhaps someone
might fetch that branch instead of using git am. It'd be more useful to
document how to produce the patch to include in the mailing list message.

Once you perform the cleanup, the patch remains in the repository but I
don't know of a way it can be fetched. Furthermore, if sourceforge run
git gc, it'll be deleted by the garbage collection.

Is there a point to these two steps that I've missed?

Note: if the cleanup step remains, it might be good to include an extra comment
on it - using git push with the source ref empty to delete a remote branch is
not the most obvious of commands to someone new to git.

Oliver

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-19 at 15:06 +0100, Oliver Kiddle wrote:
> On that basis, I've committed the change I had proposed too, excepting
> those parts that conflict with yours.

Sure, though the tone comes across as a little passive aggressive, which
hopefully is not what was intended.  We also now have *two* git workflow
sections, contradicting each other.

> Seems we need to revert some of that change, however, given that the
> patch archive does still exist. It'd also be nice not to leave the
> following question in the actual file:

That was deliberate, it is an open question.

> > +    [Open Question: should the first 6 or so characters of the commit
> > +     fingerprint be included, so: "* 12345/deadbeef: frobbed the baz"
> > ?]
> 
> I think the answer to this is "no" given the chicken and egg problem of
> getting the correct hash into the commit log. Having the fingerprint of
> the change as posted to the mailing list also seems fairly useless as
> the only other place it would persist is in the mailing list archives
> and that can be referenced with the number.

You skipped the commit numbers; my understanding of the simple process
to date is that the code change is one commit, the changelog and
integration is a second commit, see step 4.  Yes, it's an extra commit,
just for the ChangeLog.  Seems annoying, but honestly I expect folks to
spend a couple of months getting used to Git and then when everyone,
including the two most significant committers, is used to things,
things will be optimised to be more Git-like.

But that's what I understood to fall out of the previous discussion.

> I also note the following as part of your steps:
> > +  % git push origin feature_foo
> ...
> > +  [ Cleanup: ]
> > +  % git push origin :feature_foo
> 
> The first command makes the feature branch available so perhaps someone
> might fetch that branch instead of using git am. It'd be more useful to
> document how to produce the patch to include in the mailing list message.

Oh right.  Duh.  I see that's in the new workflow section.  Thanks.

> Once you perform the cleanup, the patch remains in the repository but I
> don't know of a way it can be fetched. Furthermore, if sourceforge run
> git gc, it'll be deleted by the garbage collection.

If it's in a pack, it'll be fetched in its entirety.  If it's not, it
can still be fetched by object id, until collected.

Which is the point: when the branch is no longer needed, you can delete
it from the server so that any unreferenced blobs can be garbage
collected (if nobody else re-pushes a reference via pushing the branch
back again).  If it's not needed, then the fact that it's hard to
retrieve is irrelevant, and git gc eventually running is a _good_ thing.

> Is there a point to these two steps that I've missed?

Sharing the feature, for folks who want to see it and comment, as part
of feature branch work, and then cleaning up afterwards, so we don't end
up with thousands of branches.  Sure, they're light, but that doesn't
mean housekeeping is unnecessary.

> Note: if the cleanup step remains, it might be good to include an extra comment
> on it - using git push with the source ref empty to delete a remote branch is
> not the most obvious of commands to someone new to git.

Sure.  Which is why I put it under "clean-up": it says _how_ to cleanup.
Not "why this syntax", but just gets past the "not obvious" hitch.

-Phil

Re: PATCH: document git in Etc/zsh-development-guide

[Oliver Kiddle]

Phil Pennock wrote:
> Sure, though the tone comes across as a little passive aggressive, which
> hopefully is not what was intended.  We also now have *two* git workflow
> sections, contradicting each other.

I'm sorry if the tone comes across badly.

We already had two contractory workflows and that, more so than the
sections, is what needs resolving. Unfortunately it is harder to
consolidate two contradictory workflows than to take one as a baseline
and discuss how it can be improved or where the interpretation of the
consensus from earlier discussion was wrong. I don't want to obstruct
things going forward so am happy to defer to you if you'd like to
consolidate the text in the development guide. Alternatively, if you'd
prefer, I can patch it.

> You skipped the commit numbers; my understanding of the simple process
> to date is that the code change is one commit, the changelog and
> integration is a second commit, see step 4.  Yes, it's an extra commit,

My understanding was that ChangeLog files would be handled by Peter
running Frank Terbeck's script at suitable times such as before a
release. See workers/30119.

> Sharing the feature, for folks who want to see it and comment, as part
> of feature branch work, and then cleaning up afterwards, so we don't end
> up with thousands of branches.  Sure, they're light, but that doesn't
> mean housekeeping is unnecessary.

I would keep things simple, at least initially, and stick with patches
in the mailing list as the primary means of sharing new work. It's an
easy thing to change later once the two main developers get used to git.
But, I don't really mind either way.

Oliver

Re: PATCH: document git in Etc/zsh-development-guide

[Peter Stephenson]

On Thu, 20 Dec 2012 14:38:27 +0100
Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> > You skipped the commit numbers; my understanding of the simple
> > process to date is that the code change is one commit, the
> > changelog and integration is a second commit, see step 4.  Yes,
> > it's an extra commit,
> 
> My understanding was that ChangeLog files would be handled by Peter
> running Frank Terbeck's script at suitable times such as before a
> release. See workers/30119.

We might do that at some stage, once we're convinced we're not losing
anything (I haven't properly been keeping track of Bart's comments), but
to begin with we'll keep the ChangeLog so everything isn't all changing
at once.

pws

Re: PATCH: document git in Etc/zsh-development-guide

[Bart Schaefer]

On Dec 20,  2:38pm, Oliver Kiddle wrote:
}
} Phil Pennock wrote:
} > We also now have *two* git workflow sections, contradicting each other.
} 
} We already had two contractory workflows and that, more so than the
} sections, is what needs resolving. Unfortunately it is harder to
} consolidate two contradictory workflows than to take one as a baseline
} and discuss how it can be improved or where the interpretation of the
} consensus from earlier discussion was wrong.

See, this is exactly what I was hoping would NOT happen when I suggested
that someone [*] summarize to the mailing list and everyone agree on the
summary before we started committing changes to the development guide.
I suppose one of the arguments for changing to git is that it makes this
kind of thing easier to sort out, because commits can be shared/reviewed
before being pushed to the master repository.

Thank goodness PWS tagged CVS when the -test1 tarball was created.  I'm
half tempted to cvs-admin-o back to that revision so we can start over.

[*] By which I imply someone who understands git thoroughly enough to
comprehend/consolidate everything that was being suggested, for which
I am not qualified.

Incidentally, the IP address of zsh.cvs.sourceforge.net appears to have
changed recently.  Maybe whatever it was Phil meant about SourceForge
having broken CVS, has been corrected now?  (Not that this changes any
plans.)

Re: PATCH: document git in Etc/zsh-development-guide

[Peter Stephenson]

On Thu, 20 Dec 2012 07:55:09 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Thank goodness PWS tagged CVS when the -test1 tarball was created.  I'm
> half tempted to cvs-admin-o back to that revision so we can start over.

I've updated the development guide for the release I'm just making back
to the previous version --- not that that's particularly accurate any
more, it's just not as definitively confusing.  This is very easy and
convient to do in CVS :-).

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: PATCH: document git in Etc/zsh-development-guide

[Phil Pennock]

On 2012-12-20 at 14:38 +0100, Oliver Kiddle wrote:
>                                                Alternatively, if you'd
> prefer, I can patch it.

You handle it.  Your writing is clearer than mine.

> > You skipped the commit numbers; my understanding of the simple process
> > to date is that the code change is one commit, the changelog and
> > integration is a second commit, see step 4.  Yes, it's an extra commit,
> 
> My understanding was that ChangeLog files would be handled by Peter
> running Frank Terbeck's script at suitable times such as before a
> release. See workers/30119.

Peter's confirmed I'm not crazy.  Thanks, Peter.  :)

> I would keep things simple, at least initially, and stick with patches
> in the mailing list as the primary means of sharing new work. It's an
> easy thing to change later once the two main developers get used to git.
> But, I don't really mind either way.

Right, I messed up.  I was trying to add a description of how to do the
second workflow, with sharing feature branches, so that when people
moved beyond the very simple, they'd have a guide in how to start doing
so.

I think this was a mistake on my part.

Oh, and if I go silent, it's a combination of work and travel keeping me
from commenting, not the state of zsh/git.  Please don't wait on me!

-Phil