All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, me@ikke.info
Subject: Re: [PATCH] commit & merge: modularize the empty message validator
Date: Thu, 13 Jul 2017 23:45:22 +0530	[thread overview]
Message-ID: <1499969722.5973.2.camel@gmail.com> (raw)
In-Reply-To: <xmqq8tju3eqp.fsf@gitster.mtv.corp.google.com>

On Tue, 2017-07-11 at 13:22 -0700, Junio C Hamano wrote:
> I think the "validation" done with the rest_is_empty() is somewhat
> bogus.  Why should we reject a commit without a message and a
> trailer block with only signed-off-by lines, while accepting a
> commit without a message and a trailer block as long as the trailer
> block has something equally meaningless by itself, like
> "Helped-by:"?  I think we should inspect the proposed commit log
> message taken from the editor, find its tail ignoring the trailing
> comment using ignore_non_trailer, and further separate the result
> into (<message>, <trailers>, <junk at the tail>) using the same
> logic used by the interpret-trailers tool, and then complain when
> <message> turns out to be empty, to be truly useful and consistent.
> 
I have a few doubts for which I need clarification to move on with
this. 

    1. If we abort when the <message> part is empty wouldn't it be too
    restrictive ?

    IOW, Wouldn't it affect users of "git commit -‍-cleanup=verbatim"
    who wish to commit only the comments or parts of it ?
    (I'm not sure if someone would find that useful)

    2. Is it ok to use the "find_trailer_start" function of "trailer.c"
    to locate the trailer? 

    Note: It has a little issue that it wouldn't detect the trailer if
    the message comprises of one trailer alone and no other text. This
    case occurs while aborting a commit started using "git commit -s".
    Any possibilities to overcome the issue?

    3. Ignoring point 1 for now, What other helper methods except the
    ones listed below could be helpful in the separating the cleaned up
    commit message into the <message>, <trailer>, <junk-at-tail> ?

        * ignore_non_trailer
        * find_trailer_start

-- 
Kaartic

  parent reply	other threads:[~2017-07-13 18:15 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-02 12:03 Why doesn't merge fail if message has only sign-off? Kaartic Sivaraam
2017-07-03 17:21 ` Junio C Hamano
2017-07-04 20:03   ` Kaartic Sivaraam
2017-07-06  3:31   ` [PATCH] merge-message: change meaning of "empty merge message" Kaartic Sivaraam
2017-07-06  4:46     ` Kevin Daudt
2017-07-06 12:20       ` Kaartic Sivaraam
2017-07-11 14:12       ` [PATCH] commit & merge: modularize the empty message validator Kaartic Sivaraam
2017-07-11 14:41         ` [PATCH/RFC] " Kaartic Sivaraam
2017-07-11 20:22         ` [PATCH] " Junio C Hamano
2017-07-13 13:00           ` Kaartic Sivaraam
2017-07-13 17:58             ` Junio C Hamano
2017-07-14 13:31               ` Kaartic Sivaraam
2017-07-17  9:08               ` Christian Brabandt
2017-07-17 17:16                 ` Junio C Hamano
2017-07-13 18:15           ` Kaartic Sivaraam [this message]
2017-07-13 19:23             ` Junio C Hamano
2017-07-14 17:49               ` Kaartic Sivaraam
2017-07-15  8:33                 ` Kaartic Sivaraam
2017-08-21 13:34                   ` [PATCH v2] branch: change the error messages to be more meaningful Kaartic Sivaraam
2017-08-21 13:52                     ` Kaartic Sivaraam
2017-08-21 14:05                   ` [PATCH v2/RFC] commit: change the meaning of an empty commit message Kaartic Sivaraam
2017-08-24 20:19                     ` Junio C Hamano
2017-08-31 13:36                       ` Kaartic Sivaraam
2017-10-02 17:20                         ` Kaartic Sivaraam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1499969722.5973.2.camel@gmail.com \
    --to=kaarticsivaraam91196@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ikke.info \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.