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

[Phil Pennock <zsh-workers+phil.pennock@xxxxxxxxxxxx>]

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