Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Matthieu Moy <Matthieu.Moy@xxxxxxx> writes: >> >>> Signed-off-by: Matthieu Moy <Matthieu.Moy@xxxxxxx> >>> --- >>> 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 b/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 >> string? > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html