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

[Oliver Kiddle <okiddle@xxxxxxxxxxx>]

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