From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
git@vger.kernel.org, David Turner <novalis@novalis.org>
Subject: Re: [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller
Date: Sun, 01 Jan 2017 02:36:49 -0800 [thread overview]
Message-ID: <xmqqd1g73w3i.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20161231175808.cvm54nmk3x7zoipo@sigill.intra.peff.net> (Jeff King's message of "Sat, 31 Dec 2016 12:58:08 -0500")
Jeff King <peff@peff.net> writes:
> On Sat, Dec 31, 2016 at 08:58:43AM +0100, Michael Haggerty wrote:
>
>> > The return value is always "0" or "-1". It seems like it would be
>> > simpler to just return the descriptor instead of 0.
>> >
>> > I guess that makes it hard to identify the case when we chose not to
>> > create a descriptor. I wonder if more "normal" semantics would be:
>> >
>> > 1. ret >= 0: file existed or was created, and ret is the descriptor
>> >
>> > 2. ret < 0, err is empty: we chose not to create
>> >
>> > 3. ret < 0, err is non-empty: a real error
>>
>> I don't like making callers read err to find out whether the call was
>> successful, and I think we've been able to avoid that pattern so far.
>
> I guess my mental model is that case 2 _is_ a failure, because we didn't
> open the reflog. It's just one that callers may want to distinguish from
> case 3, because it's probably a silent failure, not one we want to
> complain to the user about.
>
> But whether that's accurate would depend on the callers. Looking at the
> callers, I think the immediate callers would be happier with this, but
> you probably would want to end up converting case 3 back to "return 0"
> out of files_log_ref_write().
>
>> > I dunno. This may just be bikeshedding, and I can live with it either
>> > way (especially because you documented it!).
>>
>> Let's see if anybody has a strong opinion about it; otherwise I'd rather
>> leave it as is.
>
> Sounds good.
FWIW, in my mental model, 2. is not a failure ("we returned without
creating new log because that is what was asked by the user"). A
true failure case is "we wanted to open but couldn't".
The caller needs to be able to differentiate between these two cases
because we get no usable fd out of the function in either case.
I agree that we could cram the error status and the file descriptor
into a single return value as you two discussed, but I think what
the patch chose to do is easier to use from the callers' point of
view. The caller can switch between the codepath to give an error
message and the non-error codepath based on the return value, and in
the non-error codepath can choose what to do based on the value of
logfd.
I do not mind "all negative values mean there is no fd" plus "some
negative values are more special than others" convention, and if a
patch did that from the beginning, I certainly would not suggest to
rewrite it to use the "error status comes as a return value, file
descriptor is an out parameter" convention; i.e. I personally do not
see much difference either way, so...
next prev parent reply other threads:[~2017-01-01 10:36 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-31 3:12 [PATCH v3 00/23] Delete directories left empty after ref deletion Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 01/23] files_rename_ref(): tidy up whitespace Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 02/23] t5505: use "for-each-ref" to test for the non-existence of references Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 03/23] safe_create_leading_directories_const(): preserve errno Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 04/23] safe_create_leading_directories(): set errno on SCLD_EXISTS Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 05/23] raceproof_create_file(): new function Michael Haggerty
2016-12-31 6:11 ` Jeff King
2016-12-31 7:42 ` Michael Haggerty
2017-01-01 2:07 ` Junio C Hamano
2016-12-31 3:12 ` [PATCH v3 06/23] lock_ref_sha1_basic(): inline constant Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 07/23] lock_ref_sha1_basic(): use raceproof_create_file() Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 08/23] rename_tmp_log(): " Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 09/23] rename_tmp_log(): improve error reporting Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 10/23] log_ref_write(): inline function Michael Haggerty
2017-01-01 2:09 ` Junio C Hamano
2017-01-01 8:41 ` Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 11/23] log_ref_setup(): separate code for create vs non-create Michael Haggerty
2016-12-31 6:26 ` Jeff King
2016-12-31 7:52 ` Michael Haggerty
2017-01-01 3:28 ` Junio C Hamano
2017-01-01 8:45 ` Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 12/23] log_ref_setup(): improve robustness against races Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 13/23] log_ref_setup(): pass the open file descriptor back to the caller Michael Haggerty
2016-12-31 6:32 ` Jeff King
2016-12-31 7:58 ` Michael Haggerty
2016-12-31 17:58 ` Jeff King
2017-01-01 10:36 ` Junio C Hamano [this message]
2016-12-31 3:12 ` [PATCH v3 14/23] log_ref_write_1(): don't depend on logfile argument Michael Haggerty
2016-12-31 6:35 ` Jeff King
2016-12-31 8:01 ` Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 15/23] log_ref_setup(): manage the name of the reflog file internally Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 16/23] log_ref_write_1(): inline function Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 17/23] delete_ref_loose(): derive loose reference path from lock Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 18/23] delete_ref_loose(): inline function Michael Haggerty
2016-12-31 3:12 ` [PATCH v3 19/23] try_remove_empty_parents(): rename parameter "name" -> "refname" Michael Haggerty
2016-12-31 3:13 ` [PATCH v3 20/23] try_remove_empty_parents(): don't trash argument contents Michael Haggerty
2016-12-31 6:40 ` Jeff King
2017-01-02 16:27 ` Michael Haggerty
2017-01-02 17:10 ` Jeff King
2016-12-31 3:13 ` [PATCH v3 21/23] try_remove_empty_parents(): don't accommodate consecutive slashes Michael Haggerty
2017-01-01 2:30 ` Junio C Hamano
2017-01-01 5:59 ` Jeff King
2017-01-02 18:06 ` Michael Haggerty
2017-01-02 18:26 ` Jeff King
2016-12-31 3:13 ` [PATCH v3 22/23] try_remove_empty_parents(): teach to remove parents of reflogs, too Michael Haggerty
2016-12-31 3:13 ` [PATCH v3 23/23] files_transaction_commit(): clean up empty directories Michael Haggerty
2016-12-31 6:47 ` [PATCH v3 00/23] Delete directories left empty after ref deletion Jeff King
2017-01-01 2:32 ` Junio C Hamano
2017-01-01 9:24 ` Jacob Keller
2017-01-01 9:26 ` Jacob Keller
2017-01-01 12:43 ` Philip Oakley
2017-01-01 20:36 ` Jacob Keller
2017-01-02 4:19 ` Jeff King
2017-01-02 18:14 ` Michael Haggerty
2017-01-02 18:54 ` Jacob Keller
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=xmqqd1g73w3i.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=mhagger@alum.mit.edu \
--cc=novalis@novalis.org \
--cc=peff@peff.net \
/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).