Re: Push emails for Git

[Owen Taylor <otaylor redhat com>]

On Fri, 2009-02-13 at 18:28 +0100, Santi Béjar wrote:
> Hi,
> 
>   As the pusher, committer and the author can be different I think the
> pusher should be listed somewhere, maybe:
> 
> Subject: [gnome-shell] Bug 570579: Redo the layout of overlay components
> 
> Pushed by <userid>:
> <output of git show -p --stat>

The "pusher" is the From: of the email. 
(From: Owen Taylor <otaylor src gnome org). Do you think that is
sufficient?

> Also, and maybe it is too long, but what about putting the "git
> describe" output or something similar in the subject?
> 
> Subject: [pango PANGO_1_23_0-1-g44c9dd3] Bug 570579: Redo the layout
> of overlay components

The git contrib post-receive-email has the git-describe in the subject
but it seemed more like scary git goo to me than anything useful. If you
want the name of the commit it's right at the top of the body.

(PANGO_1_23_0-1-g44c9dd3 never seemed any more descriptive to me
than  g44c9dd3 really...)

Hmm, a cgit link to the the commit might be a nice addition.

> 2009/2/13 Owen Taylor <otaylor redhat com>:
> > Multiple commits
> > ================
> >
> > Subject: [gnome-shell] (3 commits) Merge branch 'statusmenu'...
> >
> > Summary of changes:
> >
> >  b7a0a5e... Merge branch 'statusmenu'
> >  de1c150... Add librsvg-devel to the OpenSuSE dependency list
> >
> > <output of git show -p --stat for each commit>
> >
> >
> > The detailed 'git show' output would be omitted for any commit "previously
> > in the repository". "previously in the repository" is actually impossible
> > to figure out 100% reliably, but you can do a reasonable job as long
> > as you aren't concerned that someone determined could fake it out.
> >
> > Another possibility is that we want to send out separate mails for
> > each commit in a case like the above, and never have multiple patches
> > combined into a single mail. So, you might have mails
> >
> >  Subject: [gnome-shell] [1/3] Add librsvg-devel to the OpenSuSE dependency list
> >  ...
> >  Subject: [gnome-shell] [3/3] Merge branch 'statusmenu'...
> >
> > Though I'm not quite sure how to properly represent the relationship between
> > the commits in the mails.
> 
> Maybe a "cover letter" describing the commits pushed and individual
> mails for each commit as followups.

Something like that could work.

> > Annotated tag created
> > =====================
> >
> > Subject: [gnome-shell] Created tag GNOME_SHELL_2_28_0
> >
> > The tag 'GNOME_SHELL_2_28_0' was created.
> >
> > Tagger: Owen W. Taylor <otaylor fishsoup net>
> > Date: Thu Jan 29 18:36:24 2009 -0500
> >
> >    Release gnome-shell-2.28
> >
> > Changes since the last tag 'GNOME-2.25.90':
> >
> >  2d3988c... Bug 570579: Redo the layout of overlay components
> >  de1c150... Add librsvg-devel to the OpenSuSE dependency list
> 
> "git shortlog"?

Yeah, that might work well if we think of these mails as something like
a release announcement. (the contrib post-receive-email script
even has provisions for sending annotated tag push emails to an
announce mailing list ... but that's a bit weird.)

> > Annotated tag updated
> > Annotated tag deleted
> 
> I think tag update and deletion should also be forbidden.

Branch deletion worries me more than tag deletion (since it can be used
to get around the no-non-fast-forwards restriction.) It should be
possible to recover pretty well from accidentally deleting a tag (the
tag object isn't deleted after all, jut the ref.) What do you see 
as the harm/danger?

> I also think that only annotated tags make sense in the Gnome Git
> repositories, lightweight tag should be forbidden also.

If we want to allow importing existing repositories into an empty 
git.gnome.org repository with 'git push --all --tags' then forbidding
lightweight tags might be a problem.

Thank a lot of the feedback!

- Owen