Matthieu Moy <matthieu....@grenoble-inp.fr> writes:
> Junio C Hamano <gits...@pobox.com> writes:
>> Matthieu Moy <matthieu....@imag.fr> writes:
>>> Signed-off-by: Matthieu Moy <matthieu....@imag.fr>
>>> contrib/mw-to-git/git-remote-mediawiki | 9 ++++++++-
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>> diff --git a/contrib/mw-to-git/git-remote-mediawiki
>>> index a6ad8cf..a2da52f 100755
>>> --- a/contrib/mw-to-git/git-remote-mediawiki
>>> +++ b/contrib/mw-to-git/git-remote-mediawiki
>>> @@ -51,6 +51,9 @@ use constant EMPTY_CONTENT => "<!-- empty page -->\n";
>>> # used to reflect file creation or deletion in diff.
>>> use constant NULL_SHA1 => "0000000000000000000000000000000000000000";
>>> +# Used on Git's side to reflect empty edit messages on the wiki
>>> +use constant EMPTY_MESSAGE => '*Empty MediaWiki Message*';
>> Is there a reason why this sentinel value cannot be a real empty
> That would mean having an empty commit message on the Git side, which is
> against the use (although possible with fast-import).
It also is possible with "commit --allow-empty-message", no?
> (note that the string was already there, my patch only makes it a
> constant to be able to use it in two distinct places).
It was clear from the patch text without looking beyond context, but
after all I thought this was meant to be a clean-up series, and I
simply wondered why mapping empty to some magic string was not
considered to be something to be cleaned up. That's all.
I obviously do not care that deeply either way.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html