Running interpret-trailers automatically on each commit?

Running interpret-trailers automatically on each commit?

[Jeremy Morton]

I see that interpret-trailers has been added by default in git 2.5.0. 
  However the documentation isn't that great and I can't tell whether 
it gets run automatically when I do a "git commit".  My guess is that 
it doesn't - that you have to set up a hook to get it to run each commit.

As far as I can tell, there is no way to configure global git hooks. 
Sure, you can set init.templatedir but that only applies for 
newly-init'ed or cloned repos.  So if I have 50 repos on my hard drive 
I still have to go through every one of them and set up a hook for it.

Basically, am I right in thinking that there is *still* no way for me 
to configure git (on a global, not per-repo basis) to automatically 
tack a trailer onto every commit message?  For the record, I want that 
trailer to be the current branch name.

-- 
Best regards,
Jeremy Morton (Jez)

Re: Running interpret-trailers automatically on each commit?

[Junio C Hamano]

Jeremy Morton <admin@game-point.net> writes:

> I see that interpret-trailers has been added by default in git
> 2.5.0. However the documentation isn't that great and I can't tell
> whether it gets run automatically when I do a "git commit".  My guess
> is that it doesn't - that you have to set up a hook to get it to run
> each commit.

All correct, except that it happend in 2.2 timeframe.

A new experimental feature is shipped, so that people can gain
experience with it and come up with the best practice in their
hooks, and then laster we may fold the best practice into somewhere
deeper in the system.

We are still in the early "ship an experimental feature to let
people play with it" stage.

Thanks.

Re: Running interpret-trailers automatically on each commit?

[Jeremy Morton]

Yeah but it's kind of useless to me having it on each commit on a 
per-repo basis (and even then, only with hooks).

-- 
Best regards,
Jeremy Morton (Jez)

On 28/08/2015 18:06, Junio C Hamano wrote:
> Jeremy Morton<admin@game-point.net>  writes:
>
>> I see that interpret-trailers has been added by default in git
>> 2.5.0. However the documentation isn't that great and I can't tell
>> whether it gets run automatically when I do a "git commit".  My guess
>> is that it doesn't - that you have to set up a hook to get it to run
>> each commit.
>
> All correct, except that it happend in 2.2 timeframe.
>
> A new experimental feature is shipped, so that people can gain
> experience with it and come up with the best practice in their
> hooks, and then laster we may fold the best practice into somewhere
> deeper in the system.
>
> We are still in the early "ship an experimental feature to let
> people play with it" stage.
>
> Thanks.
> --
> 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
>

Re: Running interpret-trailers automatically on each commit?

[Matthieu Moy]

Jeremy Morton <admin@game-point.net> writes:

> Yeah but it's kind of useless to me having it on each commit on a
> per-repo basis (and even then, only with hooks).

Please, don't top-post on this list.

Actually, it seems strange to me to activate it on a per-user basis.
Whether you add a trailer is usually a per-project policy. If you add a
branch trailer in each of your repository, it seems likely that some
projects you contribute to will be bothered by this.

That said, I agree it would be nice to allow a configuration-based
mechanism in addition to the current hook-based one we currently have.
But no one stepped in to implement it until now ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Running interpret-trailers automatically on each commit?

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Jeremy Morton <admin@game-point.net> writes:
>
>> Yeah but it's kind of useless to me having it on each commit on a
>> per-repo basis (and even then, only with hooks).
>
> Please, don't top-post on this list.
>
> Actually, it seems strange to me to activate it on a per-user basis.
> Whether you add a trailer is usually a per-project policy. If you add a
> branch trailer in each of your repository, it seems likely that some
> projects you contribute to will be bothered by this.
>
> That said, I agree it would be nice to allow a configuration-based
> mechanism in addition to the current hook-based one we currently have.
> But no one stepped in to implement it until now ...

Certanly.  A new experimental feature is shipped in 2.2 timeframe,
so that people can gain experience with it and come up with the best
practice in their hooks, and then laster we may fold the best
practice into somewhere deeper in the system.

We are still in the early "ship an experimental feature to let
people play with it" stage.  It is not "no one stepped in to
implement until now", but more like "no one designed what to
implement".

And we still do not have a concrete design on what to implement on
the table.  "At various points in the codebase, interpret-trailers
is invoked with some magic parameters, depending on settings of
unspecified set of configuration variables" is not a design.

Re: Running interpret-trailers automatically on each commit?

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Jeremy Morton <admin@game-point.net> writes:
>
>> Yeah but it's kind of useless to me having it on each commit on a
>> per-repo basis (and even then, only with hooks).
>
> Please, don't top-post on this list.
>
> Actually, it seems strange to me to activate it on a per-user basis.
> Whether you add a trailer is usually a per-project policy. If you add a
> branch trailer in each of your repository, it seems likely that some
> projects you contribute to will be bothered by this.
>
> That said, I agree it would be nice to allow a configuration-based
> mechanism in addition to the current hook-based one we currently have.
> But no one stepped in to implement it until now ...

Certainly.  A new experimental feature is shipped in 2.2 timeframe,
so that people can gain experience with it and come up with the best
practice in their hooks, and then laster we may fold the best
practice into somewhere deeper in the system.

We are still in the early "ship an experimental feature to let
people play with it" stage.  It is not "no one stepped in to
implement until now", but more like "no one designed what to
implement".

And we still do not have a concrete design on what to implement on
the table.  "At various points in the codebase, interpret-trailers
is invoked with some magic parameters, depending on settings of
unspecified set of configuration variables" is not a design.