[RFC] Automagic patch merge ack emails

[RFC] Automagic patch merge ack emails

[Richard Hartmann]

Hi all,

I poked around the docs, but I could not find any option to have git
send email to people who signed off a patch when it's merged.
I only realized the two patches I sent were merged because they were
listed in the RC changelog summary and would have followed up my patch
email in a about a week, asking about its status.

Does anyone else think this is useful? Does anyone else think it should
make it into main so it can be enabled via config, not via a hook that
needs to be imported into each and every repo?


Richard

Re: [RFC] Automagic patch merge ack emails

[Junio C Hamano]

"Richard Hartmann" <richih.mailinglist@gmail.com> writes:

> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.

The correcty way to say that "the changes from a patch get incorporated"
is "it's applied", not "merged".  There is no "post-am" hook you can use
to make an announcement.  Nor the sample post-commit hook that is called
after every commit mentions anything about e-mails.

And these are good things, and here is why.

It does not matter a whit to you if/when I applied your patch to a topic
branch in my private repository that I work in, preparing for eventual
pushout to the public tree.  Patches are reviewed in e-mail form, and
obvious typos and logic mistakes are corrected while still I am reading
your patch in my MUA, if they are trivial (otherwise you will get a reply
saying to which points I do not agree with your patch).  After your patch
passes this process, it may be applied somewhere, perhaps directly on
'master' or 'maint', or perhaps on a new topic branch to house your
changes.

But that is only the beginning of the story.  I'll apply many more changes
from other people, testing each step, rebasing and amending these changes
as necessary to fix breakages, and I may realize that some patches are not
quite ready to be in the public history during this process.  Your patches
may be part of these patches discarded that way.

When I decide not to apply your patch (iow, it hits my mailbox but I
reject it while it is in my MUA), git obviously would not know about it at
all [*1*].

Even after I apply your patch somewhere, I may decide not to include it in
in any of the public branches after testing and re-reviewing.  I may merge
the topic branch I created to host your patch to 'next', but after testing
and re-reviewing, I may decide it is not ready, and I'd rebuild 'next'
without the topic before pushing the results out.  And I'd delete such a
topic branch after I am done with it.

What this means is that the time a commit is made (either by patch
application or "git pull" from somebody else's tree) is too early to make
any announcement.  "git am" hook would not be useful for that purpose.

The only time that it may make a difference to you is when things are
pushed out to the public repository, and there is a mechanism for
automating tasks after new commits hits the public repository: the
post-receive hook.  contrib/hooks/post-receive-email may be a good example
to study if you are interested (I use it in my day job repository, but I
do not use the hook in git.git because the style of announcing I adopted
on this list is to send out "What's in/cooking" messages once or twice a
week).

> Does anyone else think this is useful? Does anyone else think it should
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?

If your "each and every" repository is used for the same uniform purpose
(namely, publishing to the public), then they can be initialized with the
same hook scripts using the templates mechanism, so in a sense, there
already is a mechanism for that.

But it is very unlikely your repositories are uniform, so I doubt that the
mechanism based on custom templates, or your built-in announcement
mechanism triggered by configuration, would be very useful.

Most of the freedom in a DVCS workflow comes from the separation between
making commits (including patch application and merges) and publishing the
result.  You do not want to fear committing crap, because you can
carefully check the result before making it public.

Because of that, private repositories where the real work takes place and
public repositories that serve as distribution points have very different
needs.  You do not want to have any announcement triggers in the former
(that's the whole point of separating "making commits" and "publishing the
result"), while some people like announcement triggers in the latter.

[Footnote]

*1* There are two kinds of patches that rejected that way.

 * One with good intention but wrong execution receives suggestion for
   improvements.

 * One with misguided intention or misleading description is requested to
   clarify why the change is needed, before receiving comments on the
   implementation.

Re: [RFC] Automagic patch merge ack emails

[Richard Hartmann]

On Mon, Dec 22, 2008 at 21:29, Junio C Hamano <gitster@pobox.com> wrote:

> The only time that it may make a difference to you is when things are
> pushed out to the public repository, and there is a mechanism for
> automating tasks after new commits hits the public repository: the
> post-receive hook.  contrib/hooks/post-receive-email may be a good example
> to study if you are interested (I use it in my day job repository, but I
> do not use the hook in git.git because the style of announcing I adopted
> on this list is to send out "What's in/cooking" messages once or twice a
> week).

That's pretty much what I meant, yes. As to the rest, I am still thinking
too much in VCS, not DVCS, style, I guess.
Thanks for your clarification, it all makes sense, now :)


Richard

Re: [RFC] Automagic patch merge ack emails

[Boyd Stephen Smith Jr.]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

On Monday 2008 December 22 08:07:07 Richard Hartmann wrote:
> I poked around the docs, but I could not find any option to have git
> send email to people who signed off a patch when it's merged.

There's not one, since something that that should probably be done in a hook.  
Maybe the update hook?

> I only realized the two patches I sent were merged because they were
> listed in the RC changelog summary and would have followed up my patch
> email in a about a week, asking about its status.
>
> Does anyone else think this is useful?

I think it would be nice to get a notification whenever Junio pushes commits 
to 'master' or 'maint' in git.git if I've signed off on one of the commits.  
I don't think everyone would though so the hook would need to be maintained 
indefinitely (updating the email blacklist, etc.).

It would probably be a nice hook to have as an example, I guess.

> Does anyone else think it should 
> make it into main so it can be enabled via config, not via a hook that
> needs to be imported into each and every repo?

Definitely not.  It's not that difficult to add a hook to the repositories 
that need it, and I think the majority of repositories will be private and 
not need it.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]