git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Siddharth Asthana <siddharthasthana31@gmail.com>
Cc: git@vger.kernel.org, christian.couder@gmail.com, johncai86@gmail.com
Subject: Re: [PATCH 2/3] cat-file: add mailmap support to -s option
Date: Fri, 16 Sep 2022 15:22:58 -0700	[thread overview]
Message-ID: <xmqq8rmjez7h.fsf@gitster.g> (raw)
In-Reply-To: <20220916205946.178925-3-siddharthasthana31@gmail.com> (Siddharth Asthana's message of "Sat, 17 Sep 2022 02:29:45 +0530")

Siddharth Asthana <siddharthasthana31@gmail.com> writes:

> Using `git cat-file --use-mailmap` with `-s` option, like the following is
> allowed:
>
>  git cat-file --use-mailmap -s <commit/tag object sha>
>
> The current implementation will return the same object size irrespective
> of the mailmap option, which is not as useful as it could be.
> When we
> use the mailmap mechanism to replace the idents, the size of the object
> can change and `-s` option would be more useful if it shows the size of
> the changed object. This patch implements that.

Simply put, the current implementation is BUGGY, in other words, no?

The above sounds like a quite roundabout way to say that.  "the
following is allowed" (but it does not work, really).  "is not as
useful as it could be" (it is pretty much useless, in fact).

If I were doing this step, I'd summarize it into a single three-line
paragraph, like so:

    Even though the cat-file command with -s option does not complain
    when --use-mailmap option is given, it is ignored.  Compute the size
    of the object after replacing the idents and report it instead.

>  -s::
>  	Instead of the content, show the object size identified by
> -	`<object>`.
> +	`<object>`. If used with `--use-mailmap` option, will show the
> +	size of updated object after replacing idents using the mailmap
> +	mechanism.

We are not modifying the object in the object database, so it would
be preferrable to avoid a misleading phrasing "updated object", if
we can.  The size that the object would have had, if the idents
recorded in it were the ones "corrected" by the mailmap, is what we
report.

> diff --git a/builtin/cat-file.c b/builtin/cat-file.c
> index 989eee0bb4..9942b93867 100644
> --- a/builtin/cat-file.c
> +++ b/builtin/cat-file.c
> @@ -132,8 +132,21 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
>  
>  	case 's':
>  		oi.sizep = &size;
> +
> +		if (use_mailmap) {
> +			oi.typep = &type;
> +			oi.contentp = (void**)&buf;
> +		}
> +
>  		if (oid_object_info_extended(the_repository, &oid, &oi, flags) < 0)
>  			die("git cat-file: could not get object info");
> +
> +		if (use_mailmap && (type == OBJ_COMMIT || type == OBJ_TAG)) {
> +			size_t s = size;
> +			buf = replace_idents_using_mailmap(buf, &s);
> +			size = cast_size_t_to_ulong(s);
> +		}
> +
>  		printf("%"PRIuMAX"\n", (uintmax_t)size);
>  		ret = 0;
>  		goto cleanup;

We did not grab the object contents but just asked the API to fill oi.sizep
but now we grab the contents in oi.contentp, and possibly munge it
via mailmap.

Are we merely borrowing the object contents from somebody so we do
not have to release anything before jumping to "cleanup" here?
What's the memory ownership around replace_idents_using_mailmap()?
You pass "buf" to it, and overwrite "buf" with what it returns.  If
you were responsible for releasing the original "buf" you obtained
from oid_object_info_extended(), have you lost the only pointer to
it that you may have wanted to use to release it by doing so?

    ... goes and looks ...

OK, replace_idents_using_mailmap() assumes that object_buf is owned
by the caller and the caller is willing to let it go.  That is why
it attaches it to a strbuf, calls apply_mailmap_to_header() to munge
the strbuf, and detaches.  The net effect is that the original "buf"
we took from oid_object_info_extended() may be freed inside it, and
the returned value may be a newly allocated one to replace it, so
overwriting buf is OK.

We still need to free "buf", but the function assumes that all cases
"buf" would be populated (or left to NULL) and it is OK to free it
at cleanup: label, so we are not leaking anything here.

Good.

> diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
> index cd1cab3e54..59513e7c57 100755
> --- a/t/t4203-mailmap.sh
> +++ b/t/t4203-mailmap.sh
> @@ -1022,4 +1022,14 @@ test_expect_success '--mailmap enables mailmap in cat-file for annotated tag obj
>  	test_cmp expect actual
>  '
>  
> +test_expect_success 'git cat-file -s returns correct size with --use-mailmap' '
> +	test_when_finished "rm .mailmap" &&
> +	cat >.mailmap <<-EOF &&
> +	C O Mitter <committer@example.com> Orig <orig@example.com>
> +	EOF
> +	echo "220" >expect &&
> +	git cat-file --use-mailmap -s HEAD >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_done

  reply	other threads:[~2022-09-16 22:23 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-16 20:59 [PATCH 0/3] Add mailmap mechanism in --batch-check options Siddharth Asthana
2022-09-16 20:59 ` [PATCH 1/3] doc/cat-file: allow --use-mailmap for --batch options Siddharth Asthana
2022-09-16 22:02   ` Junio C Hamano
2022-09-16 20:59 ` [PATCH 2/3] cat-file: add mailmap support to -s option Siddharth Asthana
2022-09-16 22:22   ` Junio C Hamano [this message]
2022-09-16 20:59 ` [PATCH 3/3] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-09-16 22:35   ` Junio C Hamano
2022-09-26 10:53 ` [PATCH v2 0/2] Add mailmap mechanism in cat-file options Siddharth Asthana
2022-09-26 10:53   ` [PATCH v2 1/2] cat-file: add mailmap support to -s option Siddharth Asthana
2022-09-26 13:16     ` Ævar Arnfjörð Bjarmason
2022-09-26 13:25     ` Ævar Arnfjörð Bjarmason
2022-09-26 10:53   ` [PATCH v2 2/2] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-10-29 10:24 ` [PATCH v3 0/2] Add mailmap mechanism in cat-file options Siddharth Asthana
2022-10-29 10:24   ` [PATCH v3 1/2] cat-file: add mailmap support to -s option Siddharth Asthana
2022-10-31 11:49     ` Christian Couder
2022-10-29 10:24   ` [PATCH v3 2/2] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-10-31 11:43     ` Christian Couder
2022-10-29 18:00   ` [PATCH v3 0/2] Add mailmap mechanism in cat-file options Taylor Blau
2022-11-13 21:28 ` [PATCH v4 0/3] " Siddharth Asthana
2022-11-13 21:28   ` [PATCH v4 1/3] cat-file: add mailmap support to -s option Siddharth Asthana
2022-11-13 21:28   ` [PATCH v4 2/3] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-11-15 21:40     ` Taylor Blau
2022-11-13 21:28   ` [PATCH v4 3/3] doc/cat-file: allow --use-mailmap for --batch options Siddharth Asthana
2022-11-14 17:48   ` [PATCH v4 0/3] Add mailmap mechanism in cat-file options Christian Couder
2022-11-14 22:30     ` Taylor Blau
2022-11-20  7:42     ` Siddharth Asthana
2022-11-20  7:48 ` [PATCH v5 0/2] " Siddharth Asthana
2022-11-20  7:48   ` [PATCH v5 1/2] cat-file: add mailmap support to -s option Siddharth Asthana
2022-11-21  7:27     ` Junio C Hamano
2022-11-21  9:40       ` Christian Couder
2022-11-21  9:45         ` Junio C Hamano
2022-11-21 11:27         ` Ævar Arnfjörð Bjarmason
2022-11-20  7:48   ` [PATCH v5 2/2] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-11-21  7:38     ` Junio C Hamano
2022-11-30  9:19       ` Junio C Hamano
2022-12-01 15:55 ` [PATCH v6 0/2] Add mailmap mechanism in cat-file options Siddharth Asthana
2022-12-01 15:55   ` [PATCH v6 1/2] cat-file: add mailmap support to -s option Siddharth Asthana
2022-12-01 15:55   ` [PATCH v6 2/2] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-12-14 11:27     ` Ævar Arnfjörð Bjarmason
2022-12-14 14:04     ` Christian Couder
2022-12-20  6:01 ` [PATCH v7 0/2] Add mailmap mechanism in cat-file options Siddharth Asthana
2022-12-20  6:01   ` [PATCH v7 1/2] cat-file: add mailmap support to -s option Siddharth Asthana
2022-12-20  6:01   ` [PATCH v7 2/2] cat-file: add mailmap support to --batch-check option Siddharth Asthana
2022-12-20 13:02   ` [PATCH v7 0/2] Add mailmap mechanism in cat-file options Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq8rmjez7h.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johncai86@gmail.com \
    --cc=siddharthasthana31@gmail.com \
    /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.
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).