git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mike Hommey <mh@glandium.org>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 1/2] Reuse previous annotation when overwriting a tag
Date: Sat, 03 Nov 2007 11:47:44 -0700	[thread overview]
Message-ID: <7vlk9fxj1r.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1194095285-18651-1-git-send-email-mh@glandium.org> (Mike Hommey's message of "Sat, 3 Nov 2007 14:08:04 +0100")

Mike Hommey <mh@glandium.org> writes:

> +static void write_tag_body(int fd, const unsigned char *sha1)
> +{
> ...
> +	sp = buf = read_sha1_file(sha1, &type, &size);
> +	if (!buf)
> +		return;
> +	/* skip header */
> +	sp = strstr(buf, "\n\n");

I was relieved to see this second assignment to "sp" here.

Why?

Because I wanted to say something about the first assignment to
it, that is done this way:

> +	sp = buf = read_sha1_file(sha1, &type, &size);

The original git codebase, as it came from Linus, tends to avoid
assignment to multiple variables in a single statement like this
(and that style is written down in the kernel coding style
document).  As I do not have a strong opinion against that
coding style, I've tried to follow it myself.  However, I do not
personaly have a strong argument to support enforcing the style
to others.

But in this case, as the variable "sp" is never used before it
is reassigned, I can easily say "drop the useless assignment to
sp there". ;-)

> +
> +	if (!sp || !size || type != OBJ_TAG) {
> +		free(buf);
> +		return;
> +	}
> +	sp += 2; /* skip the 2 CRs */

You are not skipping carriage returns.  You are skipping line
feeds (i.e. s/CRs/LFs/).

> @@ -282,7 +313,11 @@ static void create_tag(const unsigned char *object, const char *tag,
>  		if (fd < 0)
>  			die("could not create file '%s': %s",
>  						path, strerror(errno));
> -		write_or_die(fd, tag_template, strlen(tag_template));
> +
> +		if (prev)
> +			write_tag_body(fd, prev);
> +		else
> +			write_or_die(fd, tag_template, strlen(tag_template));
>  		close(fd);

When prev is not NULL but points at a null_sha1 nobody writes
anything out.  Is this intended?

        In fact, the calling site always passes prev which is
        prev[] in cmd_tag() and cannot be non-NULL.

Why is there "else" in the first place?  Even if you start with
the previous tag's message, you are launching the editor for the
user to further edit it, and you would want to give some
instructions, wouldn't you?
        

  parent reply	other threads:[~2007-11-03 18:48 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-03  9:31 [PATCH] Reuse previous annotation when overwriting a tag Mike Hommey
2007-11-03 11:54 ` Johannes Schindelin
2007-11-03 12:10   ` Mike Hommey
2007-11-03 12:23     ` Johannes Schindelin
2007-11-03 13:08       ` [PATCH 1/2] " Mike Hommey
2007-11-03 13:08         ` [PATCH 2/2] Small code readability improvement in show_reference() in builtin-tag.c Mike Hommey
2007-11-07 21:51           ` Mike Hommey
2007-11-03 18:47         ` Junio C Hamano [this message]
2007-11-03 19:55           ` [PATCH 1/2] Reuse previous annotation when overwriting a tag Mike Hommey
2007-11-04  0:11           ` Mike Hommey
2007-11-04  0:11             ` [PATCH 2/2] Add tests for git tag Mike Hommey
2007-11-03 12:27   ` [PATCH] Reuse previous annotation when overwriting a tag Mike Hommey
2007-11-03 12:36     ` Johannes Schindelin
2007-11-03 13:10       ` Mike Hommey
2007-11-03 13:22         ` Johannes Schindelin
2007-11-03 13:59           ` Mike Hommey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vlk9fxj1r.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).