From: Oswald Buddenhagen <oswald.buddenhagen@gmx.de>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com,
johannes.schindelin@gmx.de,
Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH v2 2/3] setup: add discover_git_directory_reason()
Date: Wed, 23 Aug 2023 11:58:17 +0200 [thread overview]
Message-ID: <ZOXYOWf/Vqfslmv4@ugly> (raw)
In-Reply-To: <787af0f9744e2f18c9ab680886650278a9d2f8d0.1692725056.git.gitgitgadget@gmail.com>
On Tue, Aug 22, 2023 at 05:24:14PM +0000, Derrick Stolee via GitGitGadget wrote:
>From: Derrick Stolee <derrickstolee@github.com>
>
>There are many reasons why discovering a Git directory may fail. In
>particular, 8959555cee7 (setup_git_directory(): add an owner check for
>the top-level directory, 2022-03-02) added ownership checks as a
>security precaution.
>
>Callers attempting to set up a Git directory may want to inform the user
>about the reason for the failure. For that, expose the enum
>discovery_result from within setup.c
>and
>
"by moving it"
>into cache.h where
>discover_git_directory() is defined.
>
>I initially wanted to change the return type of discover_git_directory()
>to be this enum, but several callers rely upon the "zero means success".
>The two problems with this are:
>
>1. The zero value of the enum is actually GIT_DIR_NONE, so nonpositive
> results are errors.
>
>2. There are multiple successful states; positive results are
> successful.
>
>It is worth noting that GIT_DIR_NONE is not returned, so we remove this
>option from the enum. We must be careful to keep the successful reasons
>as positive values, so they are given explicit positive values.
>Further, a use in scalar.c was previously impossible, so it is removed.
>
i have no clue wha this means. what is "it"?
>Instead of updating all callers immediately, add a new method,
>discover_git_directory_reason(), and convert discover_git_directory() to
>be a thin shim on top of it.
>
is this really worth it, given that there are just two callers, and the
adjustment is trivial?
if you insist, note that the function name can be easily misread as
"discover_git_(directory_reason)", which is unhelpful. i typically use
an _impl suffix in such "thin wrapper" scenarios.
regards
next prev parent reply other threads:[~2023-08-23 9:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-14 15:12 [PATCH 0/3] scalar: two downstream improvements Derrick Stolee via GitGitGadget
2023-08-14 15:12 ` [PATCH 1/3] scalar: add --[no-]src option Derrick Stolee via GitGitGadget
2023-08-14 16:02 ` Junio C Hamano
2023-08-14 19:20 ` Derrick Stolee
2023-08-14 15:12 ` [PATCH 2/3] setup: add discover_git_directory_reason() Derrick Stolee via GitGitGadget
2023-08-14 16:29 ` Junio C Hamano
2023-08-14 16:55 ` Junio C Hamano
2023-08-14 15:12 ` [PATCH 3/3] scalar reconfigure: help users remove buggy repos Derrick Stolee via GitGitGadget
2023-08-14 16:44 ` Junio C Hamano
2023-08-22 17:24 ` [PATCH v2 0/3] scalar: two downstream improvements Derrick Stolee via GitGitGadget
2023-08-22 17:24 ` [PATCH v2 1/3] scalar: add --[no-]src option Derrick Stolee via GitGitGadget
2023-08-23 9:25 ` Oswald Buddenhagen
2023-08-22 17:24 ` [PATCH v2 2/3] setup: add discover_git_directory_reason() Derrick Stolee via GitGitGadget
2023-08-22 19:30 ` Junio C Hamano
2023-08-22 19:39 ` Derrick Stolee
2023-08-23 9:58 ` Oswald Buddenhagen [this message]
2023-08-22 17:24 ` [PATCH v2 3/3] scalar reconfigure: help users remove buggy repos Derrick Stolee via GitGitGadget
2023-08-22 19:45 ` Junio C Hamano
2023-08-25 17:21 ` Derrick Stolee
2023-08-25 18:05 ` Junio C Hamano
2023-08-28 13:52 ` [PATCH v3 0/3] scalar: two downstream improvements Derrick Stolee via GitGitGadget
2023-08-28 13:52 ` [PATCH v3 1/3] scalar: add --[no-]src option Derrick Stolee via GitGitGadget
2023-08-28 13:52 ` [PATCH v3 2/3] setup: add discover_git_directory_reason() Derrick Stolee via GitGitGadget
2023-08-28 13:52 ` [PATCH v3 3/3] scalar reconfigure: help users remove buggy repos Derrick Stolee via GitGitGadget
2023-08-28 16:22 ` [PATCH v3 0/3] scalar: two downstream improvements 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=ZOXYOWf/Vqfslmv4@ugly \
--to=oswald.buddenhagen@gmx.de \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
/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.