git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git tag -s: TAG_EDITMSG should not be deleted upon failures

From
Jeff King <peff@peff.net>
Date
Dec 6, 2008, 19:40 UTC
Message-ID
<20081206194034.GA18418@coredump.intra.peff.net>
In-Reply-To
<4936AB74.3090901@jaeger.mine.nu>
tag: delete TAG_EDITMSG only on successful tag

The user may put some effort into writing an annotated tag message. When the tagging process later fails (which can happen fairly easily, since it may be dependent on gpg being correctly configured and used), there is no record left on disk of the tag message.

Instead, let's keep the TAG_EDITMSG file around until we are sure the tag has been created successfully. If we die because of an error, the user can recover their text from that file. Leaving the file in place causes no conflicts; it will be silently overwritten by the next annotated tag creation.

This matches the behavior of COMMIT_EDITMSG, which stays around in case of error.

Signed-off-by: Jeff King <peff@peff.net>
---
On Wed, Dec 03, 2008 at 04:53:24PM +0100, Christian Jaeger wrote:
Show 9 quoted lines
> Before I've now set my default signing key id in my ~/.gitconfig, I've  
> run at least half a dozen times into the case where I'm running "git tag  
> -s $tagname", carefully preparing a tag message, saving the file &  
> exiting from the editor, only to be greeted with an error message that no 
> key could be found for my (deliberately host-specific) email address, and 
> my message gone. If it would keep the TAG_EDITMSG file (like git commit 
> seems to be doing with COMMIT_EDITMSG anyway), I could rescue the message 
> from there. I relentlessly assume that this small change would also make a 
> handful of other people happier.
I think that is sensible. Here is the patch.
There are two possible improvements I can think of:
  - we can be more friendly about helping the user recover. Right now,
    we don't tell them that their message was saved anywhere, and it
    will be silently overwritten if they try another tag. I'm not sure
    what would be the best way to go about that, though.
  - the "path" variable became a little less local. It might be worth
    giving it a better name ("editmsg_path" or similar), but keeping it
    made the diff a lot less noisy (and it's still local to a fairly
    simple function).
 builtin-tag.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index d339971..ea596d2 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -260,6 +260,7 @@ static void create_tag(const unsigned char *object, const char *tag,
 	enum object_type type;
 	char header_buf[1024];
 	int header_len;
+	char *path;
 
 	type = sha1_object_info(object, NULL);
 	if (type <= OBJ_NONE)
@@ -279,7 +280,6 @@ static void create_tag(const unsigned char *object, const char *tag,
 		die("tag header too big.");
 
 	if (!message) {
-		char *path;
 		int fd;
 
 		/* write the template message before editing: */
@@ -300,9 +300,6 @@ static void create_tag(const unsigned char *object, const char *tag,
 			"Please supply the message using either -m or -F option.\n");
 			exit(1);
 		}
-
-		unlink(path);
-		free(path);
 	}
 
 	stripspace(buf, 1);
@@ -316,6 +313,9 @@ static void create_tag(const unsigned char *object, const char *tag,
 		die("unable to sign the tag");
 	if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
 		die("unable to write tag file");
+
+	unlink(path);
+	free(path);
 }
 
 struct msg_arg {
-- 
1.6.1.rc1.335.gf97227.dirty
Previous: Christian JaegerNext: Jeff King
Message 2 of 6 in “git tag -s: TAG_EDITMSG should not be deleted upon failures”
  1. Christian JaegerDec 3, 2008
  2. Jeff KingDec 6, 2008
  3. Jeff KingDec 6, 2008
  4. Junio C HamanoDec 6, 2008
  5. Jeff KingDec 6, 2008
  6. Junio C HamanoDec 6, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.