git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v4] rev-list: support human-readable output for `--disk-usage`

From
Jeff King <peff@peff.net>
Date
Aug 11, 2022, 08:38 UTC
Message-ID
<YvTACxGqVPBa+IDx@coredump.intra.peff.net>
In-Reply-To
<xmqqy1vvgxv5.fsf@gitster.g>
On Wed, Aug 10, 2022 at 10:20:14PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> I still do not see the point of changing it to print to a strbuf and
> puts() the result, though.  It does not make the code shorter, more
> efficient, or more readable.  Once "if (we are producing humanize
> format)" condition is hit, both of its branches can either be (1)
> responsible to print the number to the standard output stream, using
> whatever implementation, or (2) responsible to print the number to a
> strbuf, so that somebody outside the if statement will be
> respohnsible for printing that string to the standard output stream.

I was not the original reviewer who suggested that change, but FWIW, I think the argument for cases like these is something like this. Between:

  if (some_cond) {
    foo(do_some_prep());
  } else {
    foo(do_some_other_prep());
  }
and:
  if (some_cond) {
    x = do_some_prep();
  } else {
    x = do_some_other_prep();
  }
  foo(x);

the latter makes it more clear that foo() is called on both sides of the conditional. In this case the "foo" is not exactly the same: on one it is printing a strbuf, and on the other it is a printf that direct-formats. But the principle is the same, if you want to make it clear that both sides will result in printing something.

As you note, it loses the possibility for one side of the conditional to do its "foo" in a more efficient way, but I don't think that's very important for this particular call site.

> The patch chooses (2), which is more complex, for no good reason.  A
> good thing about (1) is that the non-human codepath can STAY to be
> the same as before, which is one fewer chance to introduce
> unnecessary bugs.
True.

Again, I don't care much either way. But I am not quite on the "I do not see the point at all" side.

-Peff
Previous: Junio C HamanoNext: Li Linchao via GitGitGadget
Message 15 of 17 in “rev-list: support `--human-readable` option when applied `disk-usage`”
  1. rev-list: support `--human-readable` option when applied `disk-usage`Li Linchao via GitGitGadget, Aug 5, 2022
  2. Ævar Arnfjörð BjarmasonAug 5, 2022
  3. lilinchao@oschina.cnAug 5, 2022
  4. rev-list: support human-readable output for `--disk-usage`Li Linchao via GitGitGadget, Aug 8, 2022
  5. lilinchao@oschina.cnAug 8, 2022
  6. Jeff KingAug 9, 2022
  7. lilinchao@oschina.cnAug 9, 2022
  8. rev-list: support human-readable output for `--disk-usage`Li Linchao via GitGitGadget, Aug 10, 2022
  9. Johannes SixtAug 10, 2022
  10. rev-list: support human-readable output for `--disk-usage`Li Linchao via GitGitGadget, Aug 10, 2022
  11. Junio C HamanoAug 10, 2022
  12. Jeff KingAug 10, 2022
  13. Junio C HamanoAug 10, 2022
  14. Junio C HamanoAug 11, 2022
  15. Jeff KingAug 11, 2022
  16. rev-list: support human-readable output for `--disk-usage`Li Linchao via GitGitGadget, Aug 11, 2022
  17. Junio C HamanoAug 11, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.