All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "John Cai via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,  John Cai <johncai86@gmail.com>
Subject: Re: [PATCH] reftable: honor core.fsync
Date: Tue, 23 Jan 2024 11:31:35 -0800	[thread overview]
Message-ID: <xmqq34unn8x4.fsf@gitster.g> (raw)
In-Reply-To: <pull.1654.git.git.1706035870956.gitgitgadget@gmail.com> (John Cai via GitGitGadget's message of "Tue, 23 Jan 2024 18:51:10 +0000")

"John Cai via GitGitGadget" <gitgitgadget@gmail.com> writes:

> This commits adds a flush function pointer as a new member of
> reftable_writer because we are not sure that the first argument to the
> *write function pointer always contains a file descriptor. In the case of
> strbuf_add_void, the first argument is a buffer. This way, we can pass
> in a corresponding flush function that knows how to flush depending on
> which writer is being used.

A comment and a half.

 * Can't the new "how to flush" go to the write-option structure?
   If you represent "no flush" as a NULL pointer in the flush member,
   most of the changes to the _test files can go, no?

 * For a function

	int func(int ac, char **av);

   a literal pointer to it can legally be written as either

	int (*funcp)(int, char **) = &func;
	int (*funcp)(int, char **) = func;

   but it is my understanding that this codebase prefers the latter,
   a tradition which goes back to 2005 when Linus was still writing
   a lot of code, i.e. the identifier that is the name of the
   function, without & in front.


  reply	other threads:[~2024-01-23 19:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-23 18:51 [PATCH] reftable: honor core.fsync John Cai via GitGitGadget
2024-01-23 19:31 ` Junio C Hamano [this message]
2024-01-23 21:42   ` John Cai
2024-01-23 21:50   ` Junio C Hamano
2024-01-24  8:41     ` Patrick Steinhardt
2024-01-24 17:22       ` Junio C Hamano
2024-01-23 21:06 ` Kristoffer Haugsbakk
2024-01-23 21:38   ` John Cai
2024-01-29  9:48 ` Patrick Steinhardt
2024-01-29 17:15   ` Junio C Hamano

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=xmqq34unn8x4.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=johncai86@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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.