Re: [PATCH 1/2] archive: replace write_or_die() calls with write_block_or_die()
- Date: Sun, 14 Apr 2019 19:33:39 +0900
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH 1/2] archive: replace write_or_die() calls with write_block_or_die()
Rohit Ashiwal <rohit.ashiwal265@xxxxxxxxx> writes:
> On 2019-04-13 1:34 UTC Jeff King <peff@xxxxxxxx> wrote:
>> What is gzwrite()?
>> I think it would be less confusing if this just factored out
>> write_block_or_die(), which starts as a thin wrapper and then grows the
>> gzip parts in the next patch.
> You are right, it might appear to someone as a bit confusing, but I feel
> like, this is the right commit to put it.
Often, the original author is the worst judge about the patch series
organization, because s/he has been staring at his or her own
patches too long and knows too much about them. Unless the author
is very experienced and is good at pretending to be the first-time
reader when proofreading his or her own patch, that is.
FWIW, I tend to agree with Peff that the organization would become
much easier to follow with "first refactor without new feature, and
in gzip related step add gzip thing".
>> Is it OK for us to ask about the truthiness of this opaque type? That
>> works if it's really a pointer behind the scenes, but it seems like it
>> would be equally OK for zlib to declare it as a struct.
Or a small integer indexing into an internal array the library keeps
track of ;-) At that point, truthiness would be completely gone, and
the compiler would not help catching "if (opaque)" as a syntax error
(if the library implements the opaque thing as a structure, then we
will be saved).
> It would be perfectly sane on zlib's part to make gzFile a struct, and if
> so happens, I'll be there to refactor the code.
We do not trust any single developer enough with "I'll do so when
needed"---in practice, it will often be done by somebody else, and
more importantly, we would want anybody to be able to take things
over, instead of relying on any one "indispensable contributor".
If it is reasonable to expect that things can easily be broken by an
external factor, I'd prefer to see us being defensive from day one.