git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* git tag -s: TAG_EDITMSG should not be deleted upon failures
@ 2008-12-03 15:53 Christian Jaeger
  2008-12-06 19:40 ` Jeff King
  0 siblings, 1 reply; 6+ messages in thread
From: Christian Jaeger @ 2008-12-03 15:53 UTC (permalink / raw
  To: Git Mailing List

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.

Christian.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
  2008-12-03 15:53 git tag -s: TAG_EDITMSG should not be deleted upon failures Christian Jaeger
@ 2008-12-06 19:40 ` Jeff King
  2008-12-06 19:42   ` Jeff King
  2008-12-06 21:28   ` Junio C Hamano
  0 siblings, 2 replies; 6+ messages in thread
From: Jeff King @ 2008-12-06 19:40 UTC (permalink / raw
  To: Christian Jaeger; +Cc: Junio C Hamano, Git Mailing List

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:

> 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

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
  2008-12-06 19:40 ` Jeff King
@ 2008-12-06 19:42   ` Jeff King
  2008-12-06 21:28   ` Junio C Hamano
  1 sibling, 0 replies; 6+ messages in thread
From: Jeff King @ 2008-12-06 19:42 UTC (permalink / raw
  To: Christian Jaeger; +Cc: Junio C Hamano, Git Mailing List

On Sat, Dec 06, 2008 at 02:40:34PM -0500, Jeff King wrote:

> Subject: Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
>
> tag: delete TAG_EDITMSG only on successful tag

Oops, of course I bungled the subject here, and the email subject should
simply be ignored.

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
  2008-12-06 19:40 ` Jeff King
  2008-12-06 19:42   ` Jeff King
@ 2008-12-06 21:28   ` Junio C Hamano
  2008-12-06 21:54     ` Jeff King
  1 sibling, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2008-12-06 21:28 UTC (permalink / raw
  To: Jeff King; +Cc: Christian Jaeger, Git Mailing List

Jeff King <peff@peff.net> writes:

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

Thanks.  I love patches that addresses bugs during -rc period.

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

There is another.

    - the "path" variable is uninitialized if we do not start editor at
      all, so unlink(path) and free(path) have a very high chance of
      failing.

      I think you need [Update #1] below squashed in to fix this.

As to your first potential improvement, I think you could do something
like [Update #2] (on top of [Update #1], of course).

[Update #1]

diff --git c/builtin-tag.c w/builtin-tag.c
index ea596d2..8086b3a 100644
--- c/builtin-tag.c
+++ w/builtin-tag.c
@@ -260,7 +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;
+	char *path = NULL;
 
 	type = sha1_object_info(object, NULL);
 	if (type <= OBJ_NONE)
@@ -314,8 +314,10 @@ static void create_tag(const unsigned char *object, const char *tag,
 	if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
 		die("unable to write tag file");
 
-	unlink(path);
-	free(path);
+	if (path) {
+		unlink(path);
+		free(path);
+	}
 }
 
 struct msg_arg {

[Update #2]

diff --git i/builtin-tag.c w/builtin-tag.c
index 8086b3a..20c1c0e 100644
--- i/builtin-tag.c
+++ w/builtin-tag.c
@@ -253,6 +253,15 @@ static void write_tag_body(int fd, const unsigned char *sha1)
 	free(buf);
 }
 
+static int build_tag_object(struct strbuf *buf, int sign, unsigned char *result)
+{
+	if (sign && do_sign(buf) < 0)
+		return error("unable to sign the tag");
+	if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
+		return error("unable to write tag file");
+	return 0;
+}
+
 static void create_tag(const unsigned char *object, const char *tag,
 		       struct strbuf *buf, int message, int sign,
 		       unsigned char *prev, unsigned char *result)
@@ -309,11 +318,12 @@ static void create_tag(const unsigned char *object, const char *tag,
 
 	strbuf_insert(buf, 0, header_buf, header_len);
 
-	if (sign && do_sign(buf) < 0)
-		die("unable to sign the tag");
-	if (write_sha1_file(buf->buf, buf->len, tag_type, result) < 0)
-		die("unable to write tag file");
-
+	if (build_tag_object(buf, sign, result) < 0) {
+		if (path)
+			fprintf(stderr, "What you edited in your editor is left in %s",
+				path);
+		exit(128);
+	}
 	if (path) {
 		unlink(path);
 		free(path);

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
  2008-12-06 21:28   ` Junio C Hamano
@ 2008-12-06 21:54     ` Jeff King
  2008-12-06 23:00       ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Jeff King @ 2008-12-06 21:54 UTC (permalink / raw
  To: Junio C Hamano; +Cc: Christian Jaeger, Git Mailing List

On Sat, Dec 06, 2008 at 01:28:50PM -0800, Junio C Hamano wrote:

> Thanks.  I love patches that addresses bugs during -rc period.

Well, I'm not sure this was a bug fix versus an improvement, but at
least wasn't an all new feature. And it was short enough to look at in
one sitting.

Of course, I did still manage to introduce a bug in my 4-line
change...;)

>     - the "path" variable is uninitialized if we do not start editor at
>       all, so unlink(path) and free(path) have a very high chance of
>       failing.
> 
>       I think you need [Update #1] below squashed in to fix this.

Oops. Yes, that is definitely a problem.

> [Update #1]
> [...]
> -	char *path;
> +	char *path = NULL;

Right, that fix looks good.

> +	if (build_tag_object(buf, sign, result) < 0) {
> +		if (path)
> +			fprintf(stderr, "What you edited in your editor is left in %s",
> +				path);
> +		exit(128);
> +	}

Much better, though the message is a bit awkward. How about

  "The tag message has been left in %s"

?

Do you want me to resend, or do you want to fix up locally?

-Peff

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: git tag -s: TAG_EDITMSG should not be deleted upon failures
  2008-12-06 21:54     ` Jeff King
@ 2008-12-06 23:00       ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2008-12-06 23:00 UTC (permalink / raw
  To: Jeff King; +Cc: Christian Jaeger, Git Mailing List

Jeff King <peff@peff.net> writes:

> Much better, though the message is a bit awkward. How about
>
>   "The tag message has been left in %s"
>
> ?
>
> Do you want me to resend, or do you want to fix up locally?

I'll squash these two plus your wording fix (with trailing LF) in to your
original patch.  Thanks.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2008-12-06 23:03 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-12-03 15:53 git tag -s: TAG_EDITMSG should not be deleted upon failures Christian Jaeger
2008-12-06 19:40 ` Jeff King
2008-12-06 19:42   ` Jeff King
2008-12-06 21:28   ` Junio C Hamano
2008-12-06 21:54     ` Jeff King
2008-12-06 23:00       ` Junio C Hamano

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).