Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

[Kaartic Sivaraam]

On Thu, 2017-08-31 at 19:06 +0530, Kaartic Sivaraam wrote:
> On Thu, 2017-08-24 at 13:19 -0700, Junio C Hamano wrote:
> > 
> > The latter is easier for me as we do not have to worry about 
> > breaking people's scripts and tools used in
> > their established workflows at all.
> > 
> 
> In that case, how about doing something similar to what was done to
> 'set-upstream' option of branch? We could print a warning notice when
> the commit message is found to be empty due to the presence of a sign-
> off line. As usual we could stop warning and stop identifying log
> messages consisting only signed-off lines as empty after a few years of
> doing that.
> 
> Note: I have no idea how good an idea this is. Let me know if it's a
> bad one.
> 


I was recently searching to find the patches have gone missing in to
the void for no obvious reason and found this. Should I consider this
to be "Dropped" in terms of the "What's cooking" emails or has this
just not received the required attention?

---
Kaartic

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

[Kaartic Sivaraam]

On Thu, 2017-08-24 at 13:19 -0700, Junio C Hamano wrote:
> 
> The latter is easier for me as we do not have to worry about 
> breaking people's scripts and tools used in
> their established workflows at all.
> 

In that case, how about doing something similar to what was done to
'set-upstream' option of branch? We could print a warning notice when
the commit message is found to be empty due to the presence of a sign-
off line. As usual we could stop warning and stop identifying log
messages consisting only signed-off lines as empty after a few years of
doing that.

Note: I have no idea how good an idea this is. Let me know if it's a
bad one.

-- 
Kaartic

Re: [PATCH v2/RFC] commit: change the meaning of an empty commit message

[Junio C Hamano]

Kaartic Sivaraam  writes:

>  As has been noted by Junio, 
>
>  "It would be a backward incompatible tightening of the established
>  rule, but it may not be a bad change."
>
>  The "It" above refers to this change. Expecting comments from people to 
> ensure
>  this change isn't a bad one.

FWIW, I am fairly neutral; I do not mind accepting this change if
other people are supportive, but I do not miss this patch if we end
up not applying it at all.  The latter is easier for me as we do not
have to worry about breaking people's scripts and tools used in
their established workflows at all.