All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Kristoffer Haugsbakk <code@khaugsbakk.name>
Cc: Taylor Blau <me@ttaylorr.com>, git@vger.kernel.org, stolee@gmail.com
Subject: Re: [PATCH v1 3/4] config: factor out global config file retrievalync-mailbox>
Date: Wed, 25 Oct 2023 07:38:52 +0200	[thread overview]
Message-ID: <ZTip7JWm-WRWTImU@tanuki> (raw)
In-Reply-To: <87badbe0-de18-4f8a-9589-314cea46065e@app.fastmail.com>

[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]

On Tue, Oct 24, 2023 at 03:23:11PM +0200, Kristoffer Haugsbakk wrote:
> Hi Taylor and Patrick
> 
> On Mon, Oct 23, 2023, at 19:40, Taylor Blau wrote:
> >> Nit: we don't know about the intent of the caller, so they may not want
> >> to write to the file but only read it.
> >
> > I was going to suggest that we allow the caller to pass in the flags
> > that they wish for git_global_config() to pass down to access(2), but
> > was surprised to see that we always use R_OK.
> >
> > But thinking on it for a moment longer, I realized that we don't care
> > about write-level permissions for the config, since we want to instead
> > open $GIT_DIR/config.lock for writing, and then rename() it into place,
> > meaning we only care about whether or not we have write permissions on
> > $GIT_DIR itself.
> >
> > I think in the existing location of this code, the "if we should write"
> > portion of the comment is premature, since we don't know for sure
> > whether or not we are writing. So I'd be fine with leaving it as-is, but
> > changing the comment seems easy enough to do...
> >
> >> > +		 * location; error out even if XDG_CONFIG_HOME
> >> > +		 * is set and points at a sane location.
> >> > +		 */
> >> > +		die(_("$HOME not set"));
> >>
> >> Is it sensible to `die()` here in this new function that behaves more
> >> like a library function? I imagine it would be more sensible to indicate
> >> the error to the user and let them handle it accordingly.
> >
> > Agreed.
> >
> > Thanks,
> > Taylor
> 
> What do you guys think the signature of `git_global_config` should be?

Either of the following:

    - `int git_global_config(char **out_pat)`
    - `char **git_global_config(void)`

In the first case you'd signal error via a non-zero return value,
whereas in the second case you would signal it via a `NULL` return
value.

To decide which one to go with I'd recommend to check whether there is
any similar precedent in "config.h" and what style that precedent uses.

Patrick

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-10-25  5:39 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 20:28 [PATCH v1 0/4] maintenance: use XDG config if it exists Kristoffer Haugsbakk
2023-10-18 20:28 ` [PATCH v1 1/4] config: format newlines Kristoffer Haugsbakk
2023-10-18 20:28 ` [PATCH v1 2/4] config: rename global config function Kristoffer Haugsbakk
2023-10-18 20:28 ` [PATCH v1 3/4] config: factor out global config file retrieval Kristoffer Haugsbakk
2023-10-23  9:58   ` Patrick Steinhardt
2023-10-23 17:40     ` [PATCH v1 3/4] config: factor out global config file retrievalync-mailbox> Taylor Blau
2023-10-24 13:23       ` Kristoffer Haugsbakk
2023-10-25  5:38         ` Patrick Steinhardt [this message]
2023-10-25  7:33           ` Kristoffer Haugsbakk
2023-10-25  8:05             ` Patrick Steinhardt
2023-10-27 15:54               ` Junio C Hamano
2023-10-18 20:28 ` [PATCH v1 4/4] maintenance: use XDG config if it exists Kristoffer Haugsbakk
2023-10-23  9:58   ` Patrick Steinhardt
2023-10-23 11:39     ` Eric Sunshine
2024-01-14 21:43 ` [PATCH v2 0/4] " Kristoffer Haugsbakk
2024-01-14 21:43   ` [PATCH v2 1/4] config: format newlines Kristoffer Haugsbakk
2024-01-14 21:43   ` [PATCH v2 2/4] config: rename global config function Kristoffer Haugsbakk
2024-01-14 21:43   ` [PATCH v2 3/4] config: factor out global config file retrieval Kristoffer Haugsbakk
2024-01-16 21:39     ` Junio C Hamano
2024-01-16 21:46       ` Kristoffer Haugsbakk
2024-01-19  6:18     ` Patrick Steinhardt
2024-01-19  7:40       ` Kristoffer Haugsbakk
2024-01-19  7:59         ` Patrick Steinhardt
2024-01-19 23:04           ` Junio C Hamano
2024-01-19 18:36         ` Junio C Hamano
2024-01-19 18:59           ` rsbecker
2024-01-14 21:43   ` [PATCH v2 4/4] maintenance: use XDG config if it exists Kristoffer Haugsbakk
2024-01-16 21:52     ` Junio C Hamano
2024-01-18 16:12 ` [PATCH v3 0/4] " Kristoffer Haugsbakk
2024-01-18 16:12   ` [PATCH v3 1/4] config: format newlines Kristoffer Haugsbakk
2024-01-18 16:12   ` [PATCH v3 2/4] config: rename global config function Kristoffer Haugsbakk
2024-01-18 16:12   ` [PATCH v3 3/4] config: factor out global config file retrieval Kristoffer Haugsbakk
2024-01-18 16:12   ` [PATCH v3 4/4] maintenance: use XDG config if it exists Kristoffer Haugsbakk

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=ZTip7JWm-WRWTImU@tanuki \
    --to=ps@pks.im \
    --cc=code@khaugsbakk.name \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=stolee@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.