Re: [RFC PATCH 1/2] commit: don't add scissors line if one exists

[Junio C Hamano <gitster@pobox.com>]

Denton Liu <liu.denton@gmail.com> writes:

>> If the current invocation of "git commit" added a scissors line in
>> the buffer to be edited already, and we are adding another one in
>> this function, is it possible that the real problem that somebody
>> else has called wt_status_add_cut_line() before this function is
>> called, in which case that other caller is what we need to fix,
>> instead of this one?
>> 
>
> In patch 2/2, I intentionally inserted a scissors line into MERGE_MSG so
> this patch ensures that we don't get duplicate scissors.

That is exactly what the paragraph you are responding to questions.
Is the code that adds a scissors line before this function is called
done the right way?  Shouldn't it be doing something differnetly?
Looking for an existing scissors looking line in this function does
not let this function differenciate two cases, i.e. we deliberately
added one already before calling this function (in which case this
function should not add another one), or we didn't add anything on
our own, but the material supplied by the end user had one (in which
case, not adding ours is losing information---imagine that the user
notices a scissors-looking line that came from the original maerial
and want to munge it, as it is part of proper message, so that it
would remain in the committed result, but because [PATCH 1/2]
stopped adding a scissors line at the right location, the user would
have to guess where to add one).

There must be an explicit way (e.g. a bit in a flag word parameter
given to this function) for the caller who knows when the new code
in [PATCH 2/2] triggers, to tell this function not to add another
one, instead of a sloppy (and less efficient) "lets's scan to see if
there already is a scissors looking line".

> With the existing behaviour, any messages that contain a scissors
> looking line will get cut at the earliest scissors anyway, so I believe
> that this patch would not change the behaviour. If the users were
> dealing with commit messages with a scissors looking line, the current
> behaviour already requires users to be extra careful to ensure that the
> scissors don't get accidentally removed so in the interest of preserving
> the existing behaviour, I don't think that any extra information would
> be lost from this patch.

Doing the "is there already a scissors looing line" approach will
*make* it harder to fix that issue, so the patch is making things
worse.