git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, gitster@pobox.com, me@ttaylorr.com,
	aevar@gmail.com, newren@gmail.com,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH 15/25] config: add git_config_get_timestamp()
Date: Fri, 11 Mar 2022 14:32:33 +0100	[thread overview]
Message-ID: <220311.86pmmshahy.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <7ec7ba3f328f9d6fa7f919ce18a138840d44ee49.1645641063.git.gitgitgadget@gmail.com>


On Wed, Feb 23 2022, Derrick Stolee via GitGitGadget wrote:

> From: Derrick Stolee <derrickstolee@github.com>
>
> The existing config parsing methods do not include a way to consistently
> parse timestamps across all platforms. Recall that "unsigned long" is
> 32 bits on 64-bit Windows, so git_config_get_ulong() is insufficient.

They do. I think you've just missed the slightly non-obviously-named
expiry-date type:

    $ for t in $(date +%s) 2.days.ago 1.week.ago; do echo $t = $(git -c x.y=$t config --type expiry-date --get x.y); done
    1647005519 = 1647005519
    2.days.ago = 1646832719
    1.week.ago = 1646400719

AFAICT there's no need for these methods, except perhaps as some wrapper
for the existing git_config_expiry_date(), perhaps to have a flag passed
down to only allow epochs, and not the human-readable format?

But for the TOC proposal I don't see why it wouldn't allow the
human-readable format. You can arguably shoot yourself in the foot with
2.days.ago, but you can also provide absolute times in that format.

In any case, peeling out this patch from this series to fast-track it if
you do need it sounds like a good idea, it would need the relevant bits
of the CLI UX implemented & docs added.

There's also tests that you'll find by grepping for "expiry-date" to
extend.

> RFC-QUESTION: Would this be better to use uintmax_t, which could be cast
> to timestamp_t or other types more robust than "unsigned long"?

I think it's certainly legitimate to re-visit that when we're talking
about making it part of a network format.

But I think we should just go for timestamp_t, it will break 32 bit
clients around the year 2038, but I think that probably the intersection
between clients who'll find this useful and those still using 32 bit
systems then will be pretty much zero :)

So I think the only thing we need for bundle-uri if it has a TOC with a
timestamp is to have it die/fallback properly if it can't parse the
values.

> [...]
> +		*dest = git_config_timestamp(key, value);
> +		return 0;
> +	} else
> +		return 1;

Nit: missing {}

>[...]
> --- a/config.h
> +++ b/config.h
> @@ -206,6 +206,7 @@ int config_with_options(config_fn_t fn, void *,
>  
>  int git_parse_ssize_t(const char *, ssize_t *);
>  int git_parse_ulong(const char *, unsigned long *);
> +int git_parse_timestamp(const char *, timestamp_t *);
>  
>  /**
>   * Same as `git_config_bool`, except that it returns -1 on error rather
> @@ -226,6 +227,11 @@ int64_t git_config_int64(const char *, const char *);
>   */
>  unsigned long git_config_ulong(const char *, const char *);
>  
> +/**
> + * Identical to `git_config_int`, but for (unsigned) timestamps.
> + */
> +timestamp_t git_config_timestamp(const char *name, const char *value);
> +
>  ssize_t git_config_ssize_t(const char *, const char *);
>  
>  /**
> @@ -469,6 +475,7 @@ int git_configset_get_string(struct config_set *cs, const char *key, char **dest
>  int git_configset_get_string_tmp(struct config_set *cs, const char *key, const char **dest);
>  int git_configset_get_int(struct config_set *cs, const char *key, int *dest);
>  int git_configset_get_ulong(struct config_set *cs, const char *key, unsigned long *dest);
> +int git_configset_get_timestamp(struct config_set *cs, const char *key, timestamp_t *dest);
>  int git_configset_get_bool(struct config_set *cs, const char *key, int *dest);
>  int git_configset_get_bool_or_int(struct config_set *cs, const char *key, int *is_bool, int *dest);
>  int git_configset_get_maybe_bool(struct config_set *cs, const char *key, int *dest);
> @@ -489,6 +496,8 @@ int repo_config_get_int(struct repository *repo,
>  			const char *key, int *dest);
>  int repo_config_get_ulong(struct repository *repo,
>  			  const char *key, unsigned long *dest);
> +int repo_config_get_timestamp(struct repository *repo,
> +			      const char *key, timestamp_t *dest);
>  int repo_config_get_bool(struct repository *repo,
>  			 const char *key, int *dest);
>  int repo_config_get_bool_or_int(struct repository *repo,
> @@ -558,6 +567,11 @@ int git_config_get_int(const char *key, int *dest);
>   */
>  int git_config_get_ulong(const char *key, unsigned long *dest);
>  
> +/**
> + * Similar to `git_config_get_int` but for (unsigned) timestamps.
> + */
> +int git_config_get_timestamp(const char *key, timestamp_t *dest);
> +

Not your fault, but it's really tiresome that whenever we need to add
stuff to this API it's this mostly copy/pasting of related methods. I
had some recent-ish patches that did something similar & it was a chore
:)

  reply	other threads:[~2022-03-11 13:41 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-23 18:30 [PATCH 00/25] [RFC] Bundle URIs Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 01/25] docs: document bundle URI standard Derrick Stolee via GitGitGadget
2022-03-02  2:28   ` Elijah Newren
2022-03-02 14:06     ` Derrick Stolee
2022-03-03  2:19       ` Elijah Newren
2022-03-03  2:44         ` Derrick Stolee
2022-02-23 18:30 ` [PATCH 02/25] bundle: alphabetize subcommands better Derrick Stolee via GitGitGadget
2022-03-11 13:47   ` Ævar Arnfjörð Bjarmason
2022-02-23 18:30 ` [PATCH 03/25] dir: extract starts_with_dot[_dot]_slash() Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 04/25] remote: move relative_url() Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 05/25] remote: allow relative_url() to return an absolute url Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 06/25] http: make http_get_file() external Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 07/25] remote-curl: add 'get' capability Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 08/25] bundle: implement 'fetch' command for direct bundles Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 09/25] bundle: parse table of contents during 'fetch' Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 10/25] bundle: add --filter option to 'fetch' Derrick Stolee via GitGitGadget
2022-03-11 13:44   ` Ævar Arnfjörð Bjarmason
2022-02-23 18:30 ` [PATCH 11/25] bundle: allow relative URLs in table of contents Derrick Stolee via GitGitGadget
2022-03-11 13:42   ` Ævar Arnfjörð Bjarmason
2022-02-23 18:30 ` [PATCH 12/25] bundle: make it easy to call 'git bundle fetch' Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 13/25] clone: add --bundle-uri option Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 14/25] clone: --bundle-uri cannot be combined with --depth Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 15/25] config: add git_config_get_timestamp() Derrick Stolee via GitGitGadget
2022-03-11 13:32   ` Ævar Arnfjörð Bjarmason [this message]
2022-02-23 18:30 ` [PATCH 16/25] bundle: only fetch bundles if timestamp is new Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 17/25] fetch: fetch bundles before fetching original data Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 18/25] connect.c: refactor sending of agent & object-format Ævar Arnfjörð Bjarmason via GitGitGadget
2022-02-23 18:30 ` [PATCH 19/25] protocol-caps: implement cap_features() Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 20/25] serve: understand but do not advertise 'features' capability Derrick Stolee via GitGitGadget
2022-02-23 18:30 ` [PATCH 21/25] serve: advertise 'features' when config exists Derrick Stolee via GitGitGadget
2022-02-23 18:31 ` [PATCH 22/25] connect: implement get_recommended_features() Derrick Stolee via GitGitGadget
2022-02-23 18:31 ` [PATCH 23/25] transport: add connections for 'features' capability Derrick Stolee via GitGitGadget
2022-02-23 18:31 ` [PATCH 24/25] clone: use server-recommended bundle URI Derrick Stolee via GitGitGadget
2022-02-23 18:31 ` [PATCH 25/25] t5601: basic bundle URI test Derrick Stolee via GitGitGadget
2022-02-23 22:17 ` [PATCH 00/25] [RFC] Bundle URIs Ævar Arnfjörð Bjarmason
2022-02-24 14:11   ` Derrick Stolee
2022-03-04 13:30     ` Derrick Stolee
2022-03-04 14:49       ` Ævar Arnfjörð Bjarmason
2022-03-04 15:12         ` Derrick Stolee
2022-03-08 17:15           ` Derrick Stolee
2022-03-10 14:45             ` Johannes Schindelin
2022-04-07 19:08             ` Derrick Stolee
2022-04-08  9:15               ` Ævar Arnfjörð Bjarmason
2022-04-08 13:13                 ` Derrick Stolee
2022-04-08 18:26                   ` Junio C Hamano
2022-03-08  8:18   ` Teng Long

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=220311.86pmmshahy.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=aevar@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@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.
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).