# [Proposal] Pass additional metadata to sendemail-validate hook from git send-email

3 messages from 2022-08-26 to 2022-08-29. Participants: Strawbridge, Michael, brian m. carlson.
Thread: https://gitlist.dev/t/58367

## Strawbridge, Michael, 2022-08-26 21:00

Subject: [Proposal] Pass additional metadata to sendemail-validate hook from git send-email
Message-ID: <87czcm7maf.fsf@amd.com>
URL: https://gitlist.dev/e/87czcm7maf.fsf%40amd.com

```
Hi,

I was hoping to put a feature proposal forward for git send-email.

For git send-email there is a git hook, sendemail-validate which 
gets the body of the email that will be sent but is missing some 
of the metadata that git send-email has access to.  I propose that 
we also pass the extra metadata that gets presented to the user 
later on via stdout such as: From, To, Cc, Subject, Date, 
Message-Id, X-Mailer, MIME-Version, Content-Transfer-Encoding to 
the git hook.

I'm willing to work on the patch but want to make sure the idea 
would be accepted first.

Thank you,
Michael
```

## brian m. carlson, 2022-08-28 00:39

Subject: Re: [Proposal] Pass additional metadata to sendemail-validate hook from git send-emailg
Message-ID: <Ywq5J2q9PwBrXnrm@tapette.crustytoothpaste.net>
URL: https://gitlist.dev/e/Ywq5J2q9PwBrXnrm%40tapette.crustytoothpaste.net
In-Reply-To: <87czcm7maf.fsf@amd.com>

```
On 2022-08-26 at 21:00:25, Strawbridge, Michael wrote:
> Hi,

Hey,

> I was hoping to put a feature proposal forward for git send-email.
> 
> For git send-email there is a git hook, sendemail-validate which
> gets the body of the email that will be sent but is missing some
> of the metadata that git send-email has access to.  I propose that
> we also pass the extra metadata that gets presented to the user
> later on via stdout such as: From, To, Cc, Subject, Date,
> Message-Id, X-Mailer, MIME-Version, Content-Transfer-Encoding to
> the git hook.
> 
> I'm willing to work on the patch but want to make sure the idea
> would be accepted first.

I think the idea is interesting and would be willing to see a patch come
to the list.

However, having said that, we typically evaluate patches, not proposals,
so to see if it's actually accepted, you'd have to actually send a
patch.  We may find that while the idea is interesting, it turns out to
be infeasible, or, for whatever reason, the patch is unsuitable.

I know that this is different from how other projects typically work,
where you typically pitch an idea first and then implement, but it's
what we do here.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

```

## Strawbridge, Michael, 2022-08-29 15:37

Subject: Re: [Proposal] Pass additional metadata to sendemail-validate hook from git send-email
Message-ID: <8735dfkqlo.fsf@amd.com>
URL: https://gitlist.dev/e/8735dfkqlo.fsf%40amd.com
In-Reply-To: <87czcm7maf.fsf@amd.com>

```

Thanks for getting back to me.  I'll write up a patch.

brian m. carlson writes:

> On 2022-08-26 at 21:00:25, Strawbridge, Michael wrote:
> > Hi,
> 
> Hey,
> 
> > I was hoping to put a feature proposal forward for git 
> > send-email.
> > 
> > For git send-email there is a git hook, sendemail-validate 
> > which
> > gets the body of the email that will be sent but is missing 
> > some
> > of the metadata that git send-email has access to.  I propose 
> > that
> > we also pass the extra metadata that gets presented to the 
> > user
> > later on via stdout such as: From, To, Cc, Subject, Date,
> > Message-Id, X-Mailer, MIME-Version, Content-Transfer-Encoding 
> > to
> > the git hook.
> > 
> > I'm willing to work on the patch but want to make sure the 
> > idea
> > would be accepted first.
> 
> I think the idea is interesting and would be willing to see a 
> patch come
> to the list.
> 
> However, having said that, we typically evaluate patches, not 
> proposals,
> so to see if it's actually accepted, you'd have to actually send 
> a
> patch.  We may find that while the idea is interesting, it turns 
> out to
> be infeasible, or, for whatever reason, the patch is unsuitable.
> 
> I know that this is different from how other projects typically 
> work,
> where you typically pitch an idea first and then implement, but 
> it's
> what we do here.
> -- 
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA

```