Re: What's cooking in git.git (Jul 2025, #08; Mon, 28)

[Patrick Steinhardt <ps@pks.im>]

On Mon, Jul 28, 2025 at 06:57:27PM -0700, Junio C Hamano wrote:
> * ps/remote-rename-fix (2025-07-28) 5 commits
>  - builtin/remote: only iterate through refs that are to be renamed
>  - builtin/remote: rework how remote refs get renamed
>  - refs: simplify logic when migrating reflog entries
>  - refs: pass refname when invoking reflog entry callback
>  - Merge branch 'ps/reflog-migrate-fixes' into ps/remote-rename-fix
>  (this branch uses ps/reflog-migrate-fixes.)
> 
>  "git remote rename origin upstream" failed to move origin/HEAD to
>  upstream/HEAD when origin/HEAD is unborn and performed other
>  renames extremely inefficiently, which has been corrected.
> 
>  Will merge to 'next'?
>  source: <20250728-pks-remote-rename-improvements-v1-0-f654f2b5c5ae@pks.im>

Let's wait a bit with this one. It's a non-trivial refactoring, so I'd
like to have a couple eyes on it.

> * ps/reflog-migrate-fixes (2025-07-24) 8 commits
>  - refs: fix invalid old object IDs when migrating reflogs
>  - refs: stop unsetting REF_HAVE_OLD for log-only updates
>  - refs: fix identity for migrated reflogs
>  - ident: fix type of string length parameter
>  - builtin/reflog: implement subcommand to write new entries
>  - refs: export `ref_transaction_update_reflog()`
>  - builtin/reflog: improve grouping of subcommands
>  - Documentation/git-reflog: convert to use synopsis type
>  (this branch is used by ps/remote-rename-fix.)
> 
>  "git refs migrate" to migrate the reflog entries from a refs
>  backend to another had a handful of bugs squashed.
> 
>  Will merge to 'next'.
>  source: <20250725-pks-reflog-append-v2-0-e4e7cbe3f578@pks.im>

There's been some discussion with Peff at [1] around one of the commits.
I plan to send another revision later today that makes this area a bit
more robust. So please hold off merging this series for now.

> * ps/config-wo-the-repository (2025-07-23) 22 commits
>  - config: fix sign comparison warnings
>  - config: move Git config parsing into "environment.c"
>  - config: remove unused `the_repository` wrappers
>  - config: drop `git_config_set_multivar()` wrapper
>  - config: drop `git_config_get_multivar_gently()` wrapper
>  - config: drop `git_config_set_multivar_in_file_gently()` wrapper
>  - config: drop `git_config_set_in_file_gently()` wrapper
>  - config: drop `git_config_set()` wrapper
>  - config: drop `git_config_set_gently()` wrapper
>  - config: drop `git_config_set_in_file()` wrapper
>  - config: drop `git_config_get_bool()` wrapper
>  - config: drop `git_config_get_ulong()` wrapper
>  - config: drop `git_config_get_int()` wrapper
>  - config: drop `git_config_get_string()` wrapper
>  - config: drop `git_config_get_string()` wrapper
>  - config: drop `git_config_get_string_multi()` wrapper
>  - config: drop `git_config_get_value()` wrapper
>  - config: drop `git_config_get_value()` wrapper
>  - config: drop `git_config_get()` wrapper
>  - config: drop `git_config_clear()` wrapper
>  - config: drop `git_config()` wrapper
>  - Merge branch 'bc/use-sha256-by-default-in-3.0' into ps/config-wo-the-repository
> 
>  The config API had a set of convenience wrapper functions that
>  implicitly use the_repository instance; they have been removed and
>  inlined at the calling sites.
> 
>  Will merge to 'next'?
>  source: <20250723-pks-config-wo-the-repository-v2-0-1502d60d3867@pks.im>

Yup, this one is ready from my perspective.

Thanks!

Patrick

[1]: <20250725113610.GA3015361@coredump.intra.peff.net>