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

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 16, 2018, 03:32 UTC
Message-ID: <xmqqzhu9lmsi.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181114180608.GA2299@archbookpro.localdomain>

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

Show 10 quoted lines

>> 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".

Show 8 quoted lines

> 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.