[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [RFC] Automagic patch merge ack emails
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2008-12-22 20:29:03
Message-ID: 7v8wq8hs34.fsf () gitster ! siamese ! dyndns ! org
[Download RAW message or body]

"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.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]