On Mon, Aug 01, 2016 at 10:58:47AM -0700, Junio C Hamano wrote:

> diff --git a/commit.c b/commit.c
> index b02f3c4..db24013 100644
> --- a/commit.c
> +++ b/commit.c
> @@ -1543,7 +1543,6 @@ int commit_tree_extended(const char *msg, size_t 
> msg_len,
>       }
>  
>       /* Person/date information */
> -     reset_ident_date();
>       if (!author)
>               author = git_author_info(IDENT_STRICT);
>       strbuf_addf(&buffer, "author %s\n", author);
> @@ -1564,11 +1563,21 @@ int commit_tree_extended(const char *msg, size_t 
> msg_len,
>       if (encoding_is_utf8 && !verify_utf8(&buffer))
>               fprintf(stderr, commit_utf8_warn);
>  
> -     if (sign_commit && do_sign_commit(&buffer, sign_commit))
> -             return -1;
> +     if (sign_commit && do_sign_commit(&buffer, sign_commit)) {
> +             result = -1;
> +             goto out;
> +     }
>  
>       result = write_sha1_file(buffer.buf, buffer.len, commit_type, ret);
> +
> +out:
>       strbuf_release(&buffer);
> +
> +     /*
> +      * Reset the default timestamp for the next call to create tag/commit
> +      * object, so that they get their own fresh timestamp.
> +      */
> +     reset_ident_date();
>       return result;
>  }

Before I switched to "reset at the beginning" in my original patch, I
also noticed this issue, but decided the other way: to only reset after
a successful creation.

I think in most cases it wouldn't matter anyway, because the caller will
generally abort as soon as this returns failure anyway. But I wondered
about something like:

  author = prepare_author_info();
  if (commit_tree_extended(..., author, ...) < 0) {
        /* oops, we failed. Do a thing and try again. */
        possible_fix();
        if (commit_tree_extended(..., author, ...) < 0)
                die("giving up");
  }

In the second call (but only the second call!) the committer and author
can diverge.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to