Re: Log messages beginning # and git rebase -i

From: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Date: Jul 29, 2015, 12:17 UTC
Message-ID: <vpq8u9zjgzl.fsf@anie.imag.fr>
In-Reply-To: <CACsJy8ABsHBA1TubB+6fypT0LGQF_O+CmHPqL+C7nMVjjWy38w@mail.gmail.com>

Duy Nguyen <pclouds@gmail.com> writes:

Show 14 quoted lines

> On Wed, Jul 29, 2015 at 12:48 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> If the user wants whatever she types in the resulting commit
>>> literally, there is the "--cleanup=<choice>" option, no?
>>
>> $ GIT_EDITOR=touch git commit --cleanup=verbatim
>> [detached HEAD 1b136a7] # Please enter the commit message for your changes. Lines starting # with '#' will be kept; you may remove them yourself if you want
>> to. # An empty message aborts the commit. # HEAD detached from 5e70007 # Changes to be committed: #     modified:   foo.txt # # Changes not staged for commit
>> : #     modified:   foo.txt # # Untracked files: #      last-synchro.txt #
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> You really don't want that in day-to-day use.
>
> How about --cleanup=scissors?

I can read this in two different ways:

1) Keeping git as-is and suggest users to use --cleanup=scissors

   This has the same problem as --cleanup=verbatim: it doesn't work as-is
   since Git doesn't insert the scissors. You can hack around it by
   adding them by yourself when you need it, but it's really not
   convenient. You have to anticipate that you're going to require a #
   and call commit with --cleanup=scissors, add the scissors. And repeat
   it if you need to "commit --amend".

2) Modify Git to add scissors by default, and use --cleanup=scissors by
   default.
 
   This is actually more or less what SVN does: it inserts a line
   "--This line, and those below, will be ignored--", and the equivalent
   of what Git adds as comments in the template is inserted below this
   line.

I don't think option 1) is good. The fact that we have the --cleanup= option shouldn't serve as an excuse to do nothing. I'd be fine with option 2), but I find it much more intrusive than to allow a simple backslash-escaping as I suggest.

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