git/pretty.c, branch v2.46.2

Merge branch 'ps/use-the-repository'

2024-07-02T16:59:00Z

A CPP macro USE_THE_REPOSITORY_VARIABLE is introduced to help transition the codebase to rely less on the availability of the singleton the_repository instance. * ps/use-the-repository: hex: guard declarations with `USE_THE_REPOSITORY_VARIABLE` t/helper: remove dependency on `the_repository` in "proc-receive" t/helper: fix segfault in "oid-array" command without repository t/helper: use correct object hash in partial-clone helper compat/fsmonitor: fix socket path in networked SHA256 repos replace-object: use hash algorithm from passed-in repository protocol-caps: use hash algorithm from passed-in repository oidset: pass hash algorithm when parsing file http-fetch: don't crash when parsing packfile without a repo hash-ll: merge with "hash.h" refs: avoid include cycle with "repository.h" global: introduce `USE_THE_REPOSITORY_VARIABLE` macro hash: require hash algorithm in `empty_tree_oid_hex()` hash: require hash algorithm in `is_empty_{blob,tree}_oid()` hash: make `is_null_oid()` independent of `the_repository` hash: convert `oidcmp()` and `oideq()` to compare whole hash global: ensure that object IDs are always padded hash: require hash algorithm in `oidread()` and `oidclr()` hash: require hash algorithm in `hasheq()`, `hashcmp()` and `hashclr()` hash: drop (mostly) unused `is_empty_{blob,tree}_sha1()` functions

global: introduce `USE_THE_REPOSITORY_VARIABLE` macro

2024-06-14T17:26:33Z

Use of the `the_repository` variable is deprecated nowadays, and we slowly but steadily convert the codebase to not use it anymore. Instead, callers should be passing down the repository to work on via parameters. It is hard though to prove that a given code unit does not use this variable anymore. The most trivial case, merely demonstrating that there is no direct use of `the_repository`, is already a bit of a pain during code reviews as the reviewer needs to manually verify claims made by the patch author. The bigger problem though is that we have many interfaces that implicitly rely on `the_repository`. Introduce a new `USE_THE_REPOSITORY_VARIABLE` macro that allows code units to opt into usage of `the_repository`. The intent of this macro is to demonstrate that a certain code unit does not use this variable anymore, and to keep it from new dependencies on it in future changes, be it explicit or implicit For now, the macro only guards `the_repository` itself as well as `the_hash_algo`. There are many more known interfaces where we have an implicit dependency on `the_repository`, but those are not guarded at the current point in time. Over time though, we should start to add guards as required (or even better, just remove them). Define the macro as required in our code units. As expected, most of our code still relies on the global variable. Nearly all of our builtins rely on the variable as there is no way yet to pass `the_repository` to their entry point. For now, declare the macro in "biultin.h" to keep the required changes at least a little bit more contained. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

pretty: add casts for decoration option pointers

2024-06-07T17:30:52Z

The `struct decoration_options` have a prefix and suffix field which are both non-constant, but we assign a constant pointer to them. This is safe to do because we pass them to `format_decorations()`, which never modifies these pointers, and then immediately discard the structure. Add explicit casts to avoid compilation warnings with `-Wwrite-strings`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

global: improve const correctness when assigning string constants

2024-06-07T17:30:48Z

We're about to enable `-Wwrite-strings`, which changes the type of string constants to `const char[]`. Fix various sites where we assign such constants to non-const variables. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

config: clarify memory ownership in `git_config_string()`

2024-05-27T18:20:00Z

The out parameter of `git_config_string()` is a `const char **` even though we transfer ownership of memory to the caller. This is quite misleading and has led to many memory leaks all over the place. Adapt the parameter to instead be `char **`. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

Merge branch 'rs/date-mode-pass-by-value'

2024-04-16T21:50:29Z

The codepaths that reach date_mode_from_type() have been updated to pass "struct date_mode" by value to make them thread safe. * rs/date-mode-pass-by-value: date: make DATE_MODE thread-safe

date: make DATE_MODE thread-safe

2024-04-05T22:21:14Z

date_mode_from_type() modifies a static variable and returns a pointer to it. This is not thread-safe. Most callers of date_mode_from_type() use it via the macro DATE_MODE and pass its result on to functions like show_date(), which take a const pointer and don't modify the struct. Avoid the static storage by putting the variable on the stack and returning the whole struct date_mode. Change functions that take a constant pointer to expect the whole struct instead. Reduce the cost of passing struct date_mode around on 64-bit systems by reordering its members to close the hole between the 32-bit wide .type and the 64-bit aligned .strftime_fmt as well as the alignment hole at the end. sizeof reports 24 before and 16 with this change on x64. Keep .type at the top to still allow initialization without designator -- though that's only done in a single location, in builtin/blame.c. Signed-off-by: René Scharfe Acked-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'bl/pretty-shorthand-config-fix'

2024-04-03T17:56:20Z

The "--pretty=" option of the commands in the "git log" family, defined as "[pretty] shortHand = " should have been looked up case insensitively, but was not, which has been corrected. * bl/pretty-shorthand-config-fix: pretty: find pretty formats case-insensitively pretty: update tests to use `test_config`

Merge branch 'jk/pretty-subject-cleanup'

2024-04-01T20:21:34Z

Code clean-up in the "git log" machinery that implements custom log message formatting. * jk/pretty-subject-cleanup: format-patch: fix leak of empty header string format-patch: simplify after-subject MIME header handling format-patch: return an allocated string from log_write_email_headers() log: do not set up extra_headers for non-email formats pretty: drop print_email_subject flag pretty: split oneline and email subject printing shortlog: stop setting pp.print_email_subject

pretty: find pretty formats case-insensitively

2024-03-25T19:19:48Z

User-defined pretty formats are stored in config, which is meant to use case-insensitive matching for names as noted in config.txt's 'Syntax' section: All the other lines [...] are recognized as setting variables, in the form 'name = value' [...]. The variable names are case-insensitive, [...]. When a user specifies one of their format aliases with an uppercase in it, however, it is not found. $ git config pretty.testAlias %h $ git config --list | grep pretty pretty.testalias=%h $ git log --format=testAlias -1 fatal: invalid --pretty format: testAlias $ git log --format=testalias -1 3c2a3fdc38 This is true whether the name in the config file uses any uppercase characters or not. Use case-insensitive comparisons when identifying format aliases. Co-authored-by: Jeff King Signed-off-by: Brian Lyles Signed-off-by: Junio C Hamano