All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Glen Choo <chooglen@google.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v1 2/3] config: introduce repo_config_set* functions
Date: Thu, 11 Nov 2021 12:24:45 -0800	[thread overview]
Message-ID: <xmqq7ddel9te.fsf@gitster.g> (raw)
In-Reply-To: <20211111171643.13805-3-chooglen@google.com> (Glen Choo's message of "Thu, 11 Nov 2021 09:16:42 -0800")

Glen Choo <chooglen@google.com> writes:

> We have git_config_set() that sets a config value for the_repository's
> config file, and repo_config_get* that reads config values from a struct
> repository. Thus, it seems reasonable to have to have
> repo_git_config_set() that can set values for a config file of a struct
> repository.
>
> Implement repo_config_set() and repo_config_set_gently(), which
> take struct repository. However, unlike other instances where struct
> repository is added to a repo_* function, this patch does not change the
> implementations of git_config_set() or git_config_set_gently(); those
> functions use the_repository much deeper in their call chain through
> git_pathdup(). Mark this inconsistency as NEEDSWORK.

Being able to only affect "config" in the_repository->gitdir is less
flexible than being able to affect "config" in repo->gitdir for any
repository is good.  Do we need a similar thing for repo->commondir
as well?

> +/*
> + * Sets a config value in a repository.
> + */
> +int repo_config_set_gently(struct repository *r, const char *key,
> +			   const char *value)
> +{
> +	int ret;
> +	char *path;
> +
> +	path = repo_git_path(r, "config");
> +	ret = git_config_set_in_file_gently(path, key, value);
> +	free(path);
> +	return ret;
> +}
> +
> +void repo_config_set(struct repository *r, const char *key, const char *value)
> +{
> +	char *path;
> +
> +	path = repo_git_path(r, "config");
> +	git_config_set_in_file(path, key, value);
> +	free(path);
> +}

Many questions:

 - What do these do for an existing key?  Add another value?
   Replace existing one?  If the latter, what do we plan to do with
   multi-valued keys?

 - Don't we need an interface to remove, rename, etc.?

 - If we call repo_config_set(repo, "key", "value") and then call
   repo_git_config_string(repo, "key", &value) on the same
   repository, do we read the value back or do we give a stale
   value?

 - A change like this should make existing config_set() that only
   works on the_repository into a thin wrapper, e.g.

	void git_config_set(const char *keyu, const char **value)
	{
		repo_config_set(the_repository, key, value);
	}

   But that is not happening here.  What prevents us from doing so?

Thanks.

  reply	other threads:[~2021-11-11 20:24 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-11 17:16 [PATCH v1 0/3] make create_branch() accept any repository Glen Choo
2021-11-11 17:16 ` [PATCH v1 1/3] refs/files-backend: remove the_repository Glen Choo
2021-11-11 17:16 ` [PATCH v1 2/3] config: introduce repo_config_set* functions Glen Choo
2021-11-11 20:24   ` Junio C Hamano [this message]
2021-11-12  0:45     ` Glen Choo
2021-11-15 22:17       ` Glen Choo
2021-11-11 17:16 ` [PATCH v1 3/3] branch: remove implicit the_repository from create_branch() Glen Choo

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=xmqq7ddel9te.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=chooglen@google.com \
    --cc=git@vger.kernel.org \
    /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.