{"thread":{"id":"66072","subject":"Assertion failure with git cat-file --batch-command","startedAt":"2026-07-27T09:30:55Z","lastAt":"2026-07-29T12:17:49Z","messageCount":8,"participants":["Alan Stokes","Jeff King","Pablo Sabater","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"549076","messageId":"CAFZW3h0K6vi15HhMEX30Ab+pjRc3mQr2Myv9KJUH=MWzsvt0FQ@mail.gmail.com","threadId":"66072","inReplyTo":null,"subject":"Assertion failure with git cat-file --batch-command","fromName":"Alan Stokes","fromEmail":"alan@source.dev","sentAt":"2026-07-27T09:30:43Z","receivedAt":"2026-07-27T09:30:55Z","isPatch":false,"body":"I unexpectedly managed to hit this:\ngit: builtin/cat-file.c:387: print_object_or_die: Assertion\n`data->info.typep' failed.\nAborted (core dumped)\n\n(That's in print_object_or_die().)\n\nHere's the bugreport.\n\nThank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n\n~$ mkdir foo\n~$ cd foo\n~/foo$ git init\nInitialized empty Git repository in /home/alan/foo/.git/\n~/foo (main)$ echo hello > hello\n~/foo (main)$ git add hello\n~/foo (main)$ git commit -m\"first\"\n[main (root-commit) d62fc70] first\n 1 file changed, 1 insertion(+)\n create mode 100644 hello\n~/foo (main)$ git ls-tree HEAD\n100644 blob ce013625030ba8dba906f756967f9e9ca394464a hello\n~/foo (main)$ echo ce013625030ba8dba906f756967f9e9ca394464a | git\ncat-file --batch=\"%(objectsize)\"\n6\nhello\n\n~/foo (main)$ echo info ce013625030ba8dba906f756967f9e9ca394464a | git\ncat-file --batch-command=\"%(objectsize)\"\n6\n~/foo (main)$ echo contents ce013625030ba8dba906f756967f9e9ca394464a |\ngit cat-file --batch-command=\"%(objecttype) %(objectsize)\"\nblob 6\nhello\n\n~/foo (main)$ echo contents ce013625030ba8dba906f756967f9e9ca394464a |\ngit cat-file --batch-command=\"%(objectsize)\"\n6\ngit: builtin/cat-file.c:387: print_object_or_die: Assertion\n`data->info.typep' failed.\nAborted (core dumped)\n\nWhat did you expect to happen? (Expected behavior)\n\ncat-file prints the size of the blob and then the blob contents\n\nWhat happened instead? (Actual behavior)\n\nAssertion failure, core dump\n\nWhat's different between what you expected and what actually happened?\n\nThe abort\n\nAnything else you want to add:\n\nI first observed this in 2.43.0, but it still seems to be present in\n2.54.0.\n\nNote that if I ask git cat-file --batch-command to include the\nobjecttype in the output it is fine (which gives me a workaround). Or\nif I use git cat-file --batch.\n\nIIUC git only fetches the metadata that it needs for each object, and\nthat is determined from the format. For --batch I guess the type is\nalways requested, since it is needed to print the object contents. But\nfor --batch-command that doesn't seem to happen.\n\nI'm not sure what the correct fix is - always request the type in\n--batch-command, or perhaps only if a \"contents\" command is issued?\n\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.54.0\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nrust: disabled\ngettext: enabled\nlibcurl: 8.5.0\nzlib: 1.3\nSHA-1: SHA1_DC\nSHA-256: SHA256_BLK\ndefault-ref-format: files\ndefault-hash: sha1\nuname: Linux 7.0.0-28-generic #28~24.04.1-Ubuntu SMP PREEMPT_DYNAMIC\nWed Jul  1 15:50:57 UTC 2 x86_64\ncompiler info: gnuc: 13.3\nlibc info: glibc: 2.39\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\n\nBest wishes,\n\nAlan\n"},{"id":"549081","messageId":"20260727095735.GA1153453@coredump.intra.peff.net","threadId":"66072","inReplyTo":"CAFZW3h0K6vi15HhMEX30Ab+pjRc3mQr2Myv9KJUH=MWzsvt0FQ@mail.gmail.com","subject":"Re: Assertion failure with git cat-file --batch-command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-27T09:57:35Z","receivedAt":"2026-07-27T09:57:37Z","isPatch":false,"body":"On Mon, Jul 27, 2026 at 10:30:43AM +0100, Alan Stokes wrote:\n\n> I first observed this in 2.43.0, but it still seems to be present in\n> 2.54.0.\n\nYeah, I think this has been there since --batch-command was added.\n\n> Note that if I ask git cat-file --batch-command to include the\n> objecttype in the output it is fine (which gives me a workaround). Or\n> if I use git cat-file --batch.\n> \n> IIUC git only fetches the metadata that it needs for each object, and\n> that is determined from the format. For --batch I guess the type is\n> always requested, since it is needed to print the object contents. But\n> for --batch-command that doesn't seem to happen.\n\nYes, exactly. In the normal --batch code path we have this code:\n\n        /*\n         * If we are printing out the object, then always fill in the type,\n         * since we will want to decide whether or not to stream.\n         */\n        if (opt->batch_mode == BATCH_MODE_CONTENTS)\n                data.info.typep = &data.type;\n\nBut for command mode, we don't do the same. This makes your case work:\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 1458dd76d6..78eab9723d 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -690,6 +690,7 @@ static void parse_cmd_contents(struct batch_options *opt,\n \t\t\t     struct expand_data *data)\n {\n \topt->batch_mode = BATCH_MODE_CONTENTS;\n+\tdata->info.typep = &data->type;\n \tbatch_one_object(line, output, opt, data);\n }\n \n\nbut there's a slight catch. That expand_data is used for every request,\nnot just the current one. In normal --batch mode, every request wants\nthe same data (the user-specified format plus the object contents). But\nin command mode, some may be \"contents\" requests and some may just be\n\"info\". The code above turns on type-checking for every request, making\nthe \"info\" ones pay to look up the type.\n\nA type lookup isn't all that expensive, but it might matter for some\nformats (e.g., just \"%(objectname)\" does an existence check and nothing\nelse, so we never even access the object data).\n\nI guess saving and restore data->info.typep would work.\n\n> I'm not sure what the correct fix is - always request the type in\n> --batch-command, or perhaps only if a \"contents\" command is issued?\n\nYeah, in general if you are asking about \"contents\" I'd expect you to\nget the full name/type/size triple. But it's not wrong to ask for less,\nand certainly we should never hit a BUG(). So I think we'd want a fix\nalong the lines above.\n\nDo you want to try your hand at a patch? It would need to do the\nsave/restore, and most importantly add a new test to t1006.\n\n-Peff\n"},{"id":"549101","messageId":"DK9MX0YJ07S0.1TOBLIA6ZNSEN@gmail.com","threadId":"66072","inReplyTo":"20260727095735.GA1153453@coredump.intra.peff.net","subject":"Re: Assertion failure with git cat-file --batch-command","fromName":"Pablo Sabater","fromEmail":"pabloosabaterr@gmail.com","sentAt":"2026-07-27T20:26:50Z","receivedAt":"2026-07-27T20:26:54Z","isPatch":false,"body":"On Mon Jul 27, 2026 at 11:57 AM CEST, Jeff King wrote:\n> On Mon, Jul 27, 2026 at 10:30:43AM +0100, Alan Stokes wrote:\n>\n>> I first observed this in 2.43.0, but it still seems to be present in\n>> 2.54.0.\n>\n> Yeah, I think this has been there since --batch-command was added.\n>\n>> Note that if I ask git cat-file --batch-command to include the\n>> objecttype in the output it is fine (which gives me a workaround). Or\n>> if I use git cat-file --batch.\n>>\n>> IIUC git only fetches the metadata that it needs for each object, and\n>> that is determined from the format. For --batch I guess the type is\n>> always requested, since it is needed to print the object contents. But\n>> for --batch-command that doesn't seem to happen.\n>\n> Yes, exactly. In the normal --batch code path we have this code:\n>\n>         /*\n>          * If we are printing out the object, then always fill in the type,\n>          * since we will want to decide whether or not to stream.\n>          */\n>         if (opt->batch_mode == BATCH_MODE_CONTENTS)\n>                 data.info.typep = &data.type;\n>\n> But for command mode, we don't do the same. This makes your case work:\n>\n> diff --git a/builtin/cat-file.c b/builtin/cat-file.c\n> index 1458dd76d6..78eab9723d 100644\n> --- a/builtin/cat-file.c\n> +++ b/builtin/cat-file.c\n> @@ -690,6 +690,7 @@ static void parse_cmd_contents(struct batch_options *opt,\n>  \t\t\t     struct expand_data *data)\n>  {\n>  \topt->batch_mode = BATCH_MODE_CONTENTS;\n> +\tdata->info.typep = &data->type;\n>  \tbatch_one_object(line, output, opt, data);\n>  }\n>\n>\n> but there's a slight catch. That expand_data is used for every request,\n> not just the current one. In normal --batch mode, every request wants\n> the same data (the user-specified format plus the object contents). But\n> in command mode, some may be \"contents\" requests and some may just be\n> \"info\". The code above turns on type-checking for every request, making\n> the \"info\" ones pay to look up the type.\n\nYes, for example, both 'info' and the 'remote-object-info' series\n(marked to 'master' in the last \"What's cooking\") [1] act on\ndata->info.typep.\n\nThis would make 'info' do a type lookup, and 'remote-object-info'\nrequest \"type\" even if it wasn't present on the format.\n\n>\n> A type lookup isn't all that expensive, but it might matter for some\n> formats (e.g., just \"%(objectname)\" does an existence check and nothing\n> else, so we never even access the object data).\n\nYes, and only the atoms in the format get expanded, a populated type\nwithout its atom in the format won't be shown.\nthe wasted lookup or a bigger request are the only effect.\n\n>\n> I guess saving and restore data->info.typep would work.\n\nYes I think that too, I tried this and it worked fine:\n\nstatic void parse_cmd_contents(struct batch_options *opt,\n\t\t\t     const char *line,\n\t\t\t     struct strbuf *output,\n\t\t\t     struct expand_data *data)\n{\n\tenum object_type *saved = data->info.typep;\n\n\topt->batch_mode = BATCH_MODE_CONTENTS;\n\tdata->info.typep = &data->type;\n\tbatch_one_object(line, output, opt, data);\n\tdata->info.typep = saved;\n}\n\nnit: On the current code the parameters aren't indented correctly.\n\n>\n>> I'm not sure what the correct fix is - always request the type in\n>> --batch-command, or perhaps only if a \"contents\" command is issued?\n>\n> Yeah, in general if you are asking about \"contents\" I'd expect you to\n> get the full name/type/size triple. But it's not wrong to ask for less,\n> and certainly we should never hit a BUG(). So I think we'd want a fix\n> along the lines above.\n>\n> Do you want to try your hand at a patch? It would need to do the\n> save/restore, and most importantly add a new test to t1006.\n>\n> -Peff\n\n[1]: https://lore.kernel.org/git/20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com/\n\nHope this helps,\nPablo\n"},{"id":"549114","messageId":"CAFZW3h3xyeJJwHfVK2mB2k1=e-0he9_gbTetJ1RdB2uUM1rp4A@mail.gmail.com","threadId":"66072","inReplyTo":"DK9MX0YJ07S0.1TOBLIA6ZNSEN@gmail.com","subject":"Re: Assertion failure with git cat-file --batch-command","fromName":"Alan Stokes","fromEmail":"alan@source.dev","sentAt":"2026-07-28T09:08:46Z","receivedAt":"2026-07-28T09:09:00Z","isPatch":false,"body":"On Mon, 27 Jul 2026 at 21:26, Pablo Sabater <pabloosabaterr@gmail.com> wrote:\n>\n> On Mon Jul 27, 2026 at 11:57 AM CEST, Jeff King wrote:\n> > On Mon, Jul 27, 2026 at 10:30:43AM +0100, Alan Stokes wrote:\n> >\n> >> I first observed this in 2.43.0, but it still seems to be present in\n> >> 2.54.0.\n> >\n> > Yeah, I think this has been there since --batch-command was added.\n> >\n> >> Note that if I ask git cat-file --batch-command to include the\n> >> objecttype in the output it is fine (which gives me a workaround). Or\n> >> if I use git cat-file --batch.\n> >>\n> >> IIUC git only fetches the metadata that it needs for each object, and\n> >> that is determined from the format. For --batch I guess the type is\n> >> always requested, since it is needed to print the object contents. But\n> >> for --batch-command that doesn't seem to happen.\n> >\n> > Yes, exactly. In the normal --batch code path we have this code:\n> >\n> >         /*\n> >          * If we are printing out the object, then always fill in the type,\n> >          * since we will want to decide whether or not to stream.\n> >          */\n> >         if (opt->batch_mode == BATCH_MODE_CONTENTS)\n> >                 data.info.typep = &data.type;\n> >\n> > But for command mode, we don't do the same. This makes your case work:\n> >\n> > diff --git a/builtin/cat-file.c b/builtin/cat-file.c\n> > index 1458dd76d6..78eab9723d 100644\n> > --- a/builtin/cat-file.c\n> > +++ b/builtin/cat-file.c\n> > @@ -690,6 +690,7 @@ static void parse_cmd_contents(struct batch_options *opt,\n> >                            struct expand_data *data)\n> >  {\n> >       opt->batch_mode = BATCH_MODE_CONTENTS;\n> > +     data->info.typep = &data->type;\n> >       batch_one_object(line, output, opt, data);\n> >  }\n> >\n> >\n> > but there's a slight catch. That expand_data is used for every request,\n> > not just the current one. In normal --batch mode, every request wants\n> > the same data (the user-specified format plus the object contents). But\n> > in command mode, some may be \"contents\" requests and some may just be\n> > \"info\". The code above turns on type-checking for every request, making\n> > the \"info\" ones pay to look up the type.\n>\n> Yes, for example, both 'info' and the 'remote-object-info' series\n> (marked to 'master' in the last \"What's cooking\") [1] act on\n> data->info.typep.\n>\n> This would make 'info' do a type lookup, and 'remote-object-info'\n> request \"type\" even if it wasn't present on the format.\n>\n> >\n> > A type lookup isn't all that expensive, but it might matter for some\n> > formats (e.g., just \"%(objectname)\" does an existence check and nothing\n> > else, so we never even access the object data).\n>\n> Yes, and only the atoms in the format get expanded, a populated type\n> without its atom in the format won't be shown.\n> the wasted lookup or a bigger request are the only effect.\n>\n> >\n> > I guess saving and restore data->info.typep would work.\n>\n> Yes I think that too, I tried this and it worked fine:\n>\n> static void parse_cmd_contents(struct batch_options *opt,\n>                              const char *line,\n>                              struct strbuf *output,\n>                              struct expand_data *data)\n> {\n>         enum object_type *saved = data->info.typep;\n>\n>         opt->batch_mode = BATCH_MODE_CONTENTS;\n>         data->info.typep = &data->type;\n>         batch_one_object(line, output, opt, data);\n>         data->info.typep = saved;\n> }\n\nThat does look pretty simple and correct.\n\n>\n> nit: On the current code the parameters aren't indented correctly.\n>\n> >\n> >> I'm not sure what the correct fix is - always request the type in\n> >> --batch-command, or perhaps only if a \"contents\" command is issued?\n> >\n> > Yeah, in general if you are asking about \"contents\" I'd expect you to\n> > get the full name/type/size triple. But it's not wrong to ask for less,\n> > and certainly we should never hit a BUG(). So I think we'd want a fix\n> > along the lines above.\n> >\n> > Do you want to try your hand at a patch? It would need to do the\n> > save/restore, and most importantly add a new test to t1006.\n\nI would be willing to have a go at it. But realistically I probably won't have\ntime for a month or two. I'm also a complete noob at the whole posting\npatches via email process, so it may be slightly chaotic. If anybody else\nwanted to deal with it I obviously wouldn't object.\n\nBest wishes,\n\nAlan\n\n> >\n> > -Peff\n>\n> [1]: https://lore.kernel.org/git/20260724-ps-eric-work-rebase-v21-0-ba67f024fdff@gmail.com/\n>\n> Hope this helps,\n> Pablo\n"},{"id":"549135","messageId":"20260728150031.GA41931@coredump.intra.peff.net","threadId":"66072","inReplyTo":"CAFZW3h3xyeJJwHfVK2mB2k1=e-0he9_gbTetJ1RdB2uUM1rp4A@mail.gmail.com","subject":"[PATCH] cat-file: handle content request for --batch-command without type","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-28T15:00:31Z","receivedAt":"2026-07-28T15:00:32Z","isPatch":true,"body":"On Tue, Jul 28, 2026 at 10:08:46AM +0100, Alan Stokes wrote:\n\n> > > Do you want to try your hand at a patch? It would need to do the\n> > > save/restore, and most importantly add a new test to t1006.\n> \n> I would be willing to have a go at it. But realistically I probably won't have\n> time for a month or two. I'm also a complete noob at the whole posting\n> patches via email process, so it may be slightly chaotic. If anybody else\n> wanted to deal with it I obviously wouldn't object.\n\nThat's long enough that I'm worried we'll forget about it. So here's a\npatch. Thanks very much for a clear bug report!\n\n-- >8 --\nSubject: cat-file: handle content request for --batch-command without type\n\nThe batch mode of cat-file needs to know the object's type in order to\nprint the contents (because it decides whether to stream or not based on\nobject type). The default batch output contains %(objecttype), so we get\nthe type info automatically. But when it doesn't, we have to ask for it\nexplicitly.\n\nIn the --batch code path, we check while setting up the object_info\nstruct whether we will print the contents, and if so set \"typep\" to get\nthe value. This comes from 6554dfa97a (cat-file: handle --batch format\nwith missing type/size, 2013-12-12).\n\nBut later we added a --batch-command mode, which does not do the same\ntrick. The decision about whether to retrieve the contents is made\nper-command (a \"contents\" vs \"info\" command), so we can't decide when\nbuilding the object_info originally. As a result, asking for:\n\n  echo \"contents HEAD\" | git cat-file --batch-command=\"%(objectname)\"\n\nwill fail the assertion in print_object_or_die() that the type was\nactually filled in.\n\nWe can fix it by tweaking the object_info on the fly as we receive each\ncommand. But we should be careful to restore it afterwards; otherwise a\nsequence of commands like:\n\n  contents $one\n  info $two\n  info $three\n\nwill pay the type-lookup price for $two and $three when it does not need\nto. This wouldn't be incorrect, but just slightly inefficient (and hence\nthere are no tests for that part, because the externally-visible\nbehavior is the same).\n\nReported-by: Alan Stokes <alan@source.dev>\nHelped-by: Pablo Sabater <pabloosabaterr@gmail.com>\nSigned-off-by: Jeff King <peff@peff.net>\n---\n builtin/cat-file.c  | 3 +++\n t/t1006-cat-file.sh | 8 ++++++++\n 2 files changed, 11 insertions(+)\n\ndiff --git a/builtin/cat-file.c b/builtin/cat-file.c\nindex 1458dd76d6..ac458c9737 100644\n--- a/builtin/cat-file.c\n+++ b/builtin/cat-file.c\n@@ -689,8 +689,11 @@ static void parse_cmd_contents(struct batch_options *opt,\n \t\t\t     struct strbuf *output,\n \t\t\t     struct expand_data *data)\n {\n+\tenum object_type *saved_typep = data->info.typep;\n+\tdata->info.typep = &data->type;\n \topt->batch_mode = BATCH_MODE_CONTENTS;\n \tbatch_one_object(line, output, opt, data);\n+\tdata->info.typep = saved_typep;\n }\n \n static void parse_cmd_info(struct batch_options *opt,\ndiff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh\nindex 762c77c351..f085738082 100755\n--- a/t/t1006-cat-file.sh\n+++ b/t/t1006-cat-file.sh\n@@ -1351,6 +1351,14 @@ test_expect_success 'batch-command flush without --buffer' '\n \ttest_grep \"^fatal:.*flush is only for --buffer mode.*\" err\n '\n \n+test_expect_success 'batch-command contents auto-handles type' '\n+\techo \"HEAD\" |\n+\t\tgit cat-file --batch=\"%(objectname)\" >expect &&\n+\techo \"contents HEAD\" |\n+\t\tgit cat-file --batch-command=\"%(objectname)\" >actual &&\n+\ttest_cmp expect actual\n+'\n+\n perl_script='\n use warnings;\n use strict;\n-- \n2.55.0.749.g30c495c7a6\n\n"},{"id":"549157","messageId":"xmqqjyqfdnie.fsf@gitster.g","threadId":"66072","inReplyTo":"20260728150031.GA41931@coredump.intra.peff.net","subject":"Re: [PATCH] cat-file: handle content request for --batch-command without type","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2026-07-28T17:36:57Z","receivedAt":"2026-07-28T17:36:59Z","isPatch":true,"body":"Jeff King <peff@peff.net> writes:\n\n> We can fix it by tweaking the object_info on the fly as we receive each\n> command. But we should be careful to restore it afterwards; otherwise a\n> sequence of commands like:\n>\n>   contents $one\n>   info $two\n>   info $three\n>\n> will pay the type-lookup price for $two and $three when it does not need\n> to. This wouldn't be incorrect, but just slightly inefficient (and hence\n> there are no tests for that part, because the externally-visible\n> behavior is the same).\n\nWoooo, tricky.  I love this kind of attention to details.\n\nThe patch text obviously is correct.\n\nWill queue and mark the topic for 'next'.  Thanks.\n\n\n> Reported-by: Alan Stokes <alan@source.dev>\n> Helped-by: Pablo Sabater <pabloosabaterr@gmail.com>\n> Signed-off-by: Jeff King <peff@peff.net>\n> ---\n>  builtin/cat-file.c  | 3 +++\n>  t/t1006-cat-file.sh | 8 ++++++++\n>  2 files changed, 11 insertions(+)\n>\n> diff --git a/builtin/cat-file.c b/builtin/cat-file.c\n> index 1458dd76d6..ac458c9737 100644\n> --- a/builtin/cat-file.c\n> +++ b/builtin/cat-file.c\n> @@ -689,8 +689,11 @@ static void parse_cmd_contents(struct batch_options *opt,\n>  \t\t\t     struct strbuf *output,\n>  \t\t\t     struct expand_data *data)\n>  {\n> +\tenum object_type *saved_typep = data->info.typep;\n> +\tdata->info.typep = &data->type;\n>  \topt->batch_mode = BATCH_MODE_CONTENTS;\n>  \tbatch_one_object(line, output, opt, data);\n> +\tdata->info.typep = saved_typep;\n>  }\n>  \n>  static void parse_cmd_info(struct batch_options *opt,\n> diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh\n> index 762c77c351..f085738082 100755\n> --- a/t/t1006-cat-file.sh\n> +++ b/t/t1006-cat-file.sh\n> @@ -1351,6 +1351,14 @@ test_expect_success 'batch-command flush without --buffer' '\n>  \ttest_grep \"^fatal:.*flush is only for --buffer mode.*\" err\n>  '\n>  \n> +test_expect_success 'batch-command contents auto-handles type' '\n> +\techo \"HEAD\" |\n> +\t\tgit cat-file --batch=\"%(objectname)\" >expect &&\n> +\techo \"contents HEAD\" |\n> +\t\tgit cat-file --batch-command=\"%(objectname)\" >actual &&\n> +\ttest_cmp expect actual\n> +'\n> +\n>  perl_script='\n>  use warnings;\n>  use strict;\n"},{"id":"549196","messageId":"CAFZW3h2hVMaVy12uO_5k5cwN=N9LDhrxuVSQPNmPWxB4j+kRwQ@mail.gmail.com","threadId":"66072","inReplyTo":"xmqqjyqfdnie.fsf@gitster.g","subject":"Re: [PATCH] cat-file: handle content request for --batch-command without type","fromName":"Alan Stokes","fromEmail":"alan@source.dev","sentAt":"2026-07-29T10:03:34Z","receivedAt":"2026-07-29T10:03:47Z","isPatch":true,"body":"On Tue, 28 Jul 2026 at 18:36, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> Jeff King <peff@peff.net> writes:\n>\n> > We can fix it by tweaking the object_info on the fly as we receive each\n> > command. But we should be careful to restore it afterwards; otherwise a\n> > sequence of commands like:\n> >\n> >   contents $one\n> >   info $two\n> >   info $three\n> >\n> > will pay the type-lookup price for $two and $three when it does not need\n> > to. This wouldn't be incorrect, but just slightly inefficient (and hence\n> > there are no tests for that part, because the externally-visible\n> > behavior is the same).\n>\n> Woooo, tricky.  I love this kind of attention to details.\n>\n> The patch text obviously is correct.\n>\n> Will queue and mark the topic for 'next'.  Thanks.\n\nThanks, Peff and Pablo. Sorry I wasn't able to contribute this time.\n\n(Peff: for some reason I'm not receiving emails from you, although\nI've got the other ones on this thread. I'm assuming that's due to\nsome over-zealous filter at my end.)\n\nBest wishes,\n\nAlan\n"},{"id":"549201","messageId":"20260729121747.GA679014@coredump.intra.peff.net","threadId":"66072","inReplyTo":"CAFZW3h2hVMaVy12uO_5k5cwN=N9LDhrxuVSQPNmPWxB4j+kRwQ@mail.gmail.com","subject":"Re: [PATCH] cat-file: handle content request for --batch-command without type","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2026-07-29T12:17:47Z","receivedAt":"2026-07-29T12:17:49Z","isPatch":true,"body":"On Wed, Jul 29, 2026 at 11:03:34AM +0100, Alan Stokes wrote:\n\n> Thanks, Peff and Pablo. Sorry I wasn't able to contribute this time.\n\nReporting the bug is a very important form of contribution. :)\n\n> (Peff: for some reason I'm not receiving emails from you, although\n> I've got the other ones on this thread. I'm assuming that's due to\n> some over-zealous filter at my end.)\n\nThanks for letting me know. The problem was on my end, and (shocker) it\nturned out to be DNS.\n\n-Peff\n"}]}