Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> The first empty line in a tag object separates the header from the
> message. If the tag object has no empty line, do not crash, but
> complain loudly instead.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@xxxxxx>
> ---
>
> I have no idea how this tag crept into one of my repos, but it is
> no good to crash for git-fsck.
Absolutely. git-fsck is to find suspicious data and should not
crash on them.
Thanks.
But it _does_ make me wonder how. Recent git-tag does this
( printf 'object %s\ntype %s\ntag %s\ntagger %s\n\n' \
"$object" "$type" "$name" "$tagger";
cat "$GIT_DIR"/TAG_FINALMSG ) >"$GIT_DIR"/TAG_TMP
so even if TAG_FINALMSG (which is -m or edited message after
filtering out the comments and git-stripspace) is empty, you
would have the two LFs at the end of the header. Ancient
"git-tag-script" did this, which is a moral equivalent with echo
and has the same effect:
( echo -e "object $object\ntype $type\ntag $name\ntagger $tagger\n";
cat .tagmsg ) > .tmp-t
Did this tag come from cvsimport (or svnimport) perhaps? We are
in the process of updating its use of git-mktag to git-tag, but
they use git-mktag and do not leave a blank line after the
header (and they do not add any body).
I notice that gitk creates lightweight tag by hand (it directly
goes to the filesystem) It should probably use git-tag as well.
I agree with you that if something does not have body, we should
not require an empty trailing line after the header.
-
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
