mailmap: change primary address for Glen Choo

From: Glen Choo <chooglen@google.com>

Glen will lose access to his work email soon.

Signed-off-by: Glen Choo <chooglen@google.com>

Submitted-As: https://lore.kernel.org/git/pull.1561.git.git.1691433710768.gitgitgadget@gmail.com

maintenance: schedule maintenance on a random minute

When we initially created background maintenance -- with its hourly, daily,
and weekly schedules -- we considered the effects of all clients launching
fetches to the server every hour on the hour. The worry of DDoSing server
hosts was noted, but left as something we would consider for a future
update.

As background maintenance has gained more adoption over the past three
years, our worries about DDoSing the big Git hosts has been unfounded. Those
systems, especially those serving public repositories, are already resilient
to thundering herds of much smaller scale.

However, sometimes organizations spin up specific custom server
infrastructure either in addition to or on top of their Git host. Some of
these technologies are built for a different range of scale, and can hit
concurrency limits sooner. Organizations with such custom infrastructures
are more likely to recommend tools like scalar which furthers their adoption
of background maintenance.

This series attempts to help by spreading out background maintenance to a
random minute of the hour. This minute is selected during git maintenance
start, and the same minute applies to each of the three schedules.

This isn't a full solution to this problem, as the custom infrastructure
needs to be resilient to bursts of activity, but at least this will help
somewhat.

Each of the integrated schedulers needs a different way of integrating the
random minute. The most problematic is systemd, since our integration had a
clever use of templates to write one schedule that inserted the hourly,
daily, and weekly schedules as a string into the template. This needs some
refactoring before the custom minute could be inserted.

For the most part, each scheduler's integration is relatively simple. That
is, until we get to the systemd integration. That integration made use of a
clever templating technique that is no longer possible when making this
adjustment. The last two patches involve systemd, though one is just a move
of code (without edits) to make the second's diff look a lot simpler.

Thanks, -Stolee

Derrick Stolee (6):
  maintenance: add get_random_minute()
  maintenance: use random minute in launchctl scheduler
  maintenance: use random minute in Windows scheduler
  maintenance: use random minute in cron scheduler
  maintenance: swap method locations
  maintenance: use random minute in systemd scheduler

 builtin/gc.c           | 259 ++++++++++++++++++++++++++---------------
 t/t7900-maintenance.sh |   4 +-
 2 files changed, 166 insertions(+), 97 deletions(-)

base-commit: fe86abd

Submitted-As: https://lore.kernel.org/git/pull.1567.git.1691434300.gitgitgadget@gmail.com

ls-tree: default <tree-ish> to HEAD

From: Ryan Williams <ryan@runsascoded.com>

When no positional arguments are passed to `git ls-tree`, it currently
prints "usage" info to stderr and exits with code 129. A more intuitive
default would be to operate on the `HEAD` commit's tree (similarly to
`git show`, `git log`, and possibly others).

This patch updates `git ls-tree [options...]` to operate identically to
`git ls-tree [options...] HEAD`, updates the docs to reflect that
`<tree-ish>` is optional (and `[path...]` args can only be provided if a
`<tree-ish>` is explicitly provided first), and duplicates some existing
test cases to omit the `HEAD` argument to `ls-tree` (verifying that
`ls-tree` behaves identically whether `HEAD` is provided or not).

Signed-off-by: Ryan Williams <ryan@runsascoded.com>

Submitted-As: https://lore.kernel.org/git/pull.1566.git.1691412557518.gitgitgadget@gmail.com

merge-tree: add -X strategy option

From: winglovet <winglovet@gmail.com>

Add merge strategy option to produce more customizable merge result such
as automatically solve conflicts.

Signed-off-by: winglovet <winglovet@gmail.com>

Submitted-As: https://lore.kernel.org/git/pull.1565.git.1691245481977.gitgitgadget@gmail.com

Fixes to trailer test script, help text, and documentation

This series contains various fixes to the trailer code. They pertain to
fixes to the test script, the command line help text for the
interpret-trailers builtin, and the documentation.

Patch 1 is the biggest one, but also perhaps the most important as it does
cleanups in the tests where we used 'git config' in a test case without
cleaning up that state for the next test. This makes the tests
self-contained, making it easier to add new tests anywhere along the script,
without worrying about previously-set implicit state. These test cleanups
exposed lots of cases where the test cases are mutating more configuration
state than is necessary to test the specific behavior in the test; however
such extraneous configurations were not cleaned up to make these patches
easier to review (again, we are not changing any behavior and we are also
not changing what the test cases themselves purport to do).

Note that Patch 1 was originally a 22-commit series, but was squashed
together to make it easier to see the final diff for each test case. You can
see the 22-commit breakdown at
https://github.com/listx/git/tree/backup-trailer-22-commit-breakdown

Patch 3 adds some tests to check the behavior of '--no-if-exists' and
'--no-if-missing', which weren't previously tested. It also adds
similarly-themed test cases for '--no-where' which only had 1 test case for
it.

The other patches aren't as important, but are included here because I think
they are too small to include in a separate series.

Linus Arver (5):
  trailer tests: make test cases self-contained
  trailer test description: this tests --where=after, not --where=before
  trailer: add tests to check defaulting behavior with --no-* flags
  trailer: trailer location is a place, not an action
  trailer --no-divider help: describe usual "---" meaning

 Documentation/git-interpret-trailers.txt |  14 +-
 builtin/interpret-trailers.c             |   4 +-
 t/t7513-interpret-trailers.sh            | 506 +++++++++++++++++++----
 3 files changed, 443 insertions(+), 81 deletions(-)

base-commit: 1b0a512

Submitted-As: https://lore.kernel.org/git/pull.1564.git.1691210737.gitgitgadget@gmail.com

Trailer readability cleanups

These patches were created while digging into the trailer code to better
understand how it works, in preparation for making the trailer.{c,h} files
as small as possible to make them available as a library for external users.
This series was originally created as part of [1], but are sent here
separately because the changes here are arguably more subjective in nature.
I think Patch 1 is the most important in this series. The others can wait,
if folks are opposed to adding them on their own merits at this point in
time.

These patches do not add or change any features. Instead, their goal is to
make the code easier to understand for new contributors (like myself), by
making various cleanups and improvements. Ultimately, my hope is that with
such cleanups, we are better positioned to make larger changes (especially
the broader libification effort, as in "Introduce Git Standard Library"
[2]).

Patch 1 was inspired by 576de3d (unpack_trees: start splitting internal
fields from public API, 2023-02-27) [3], and is in preparation for a
libification effort in the future around the trailer code. Independent of
libification, it still makes sense to discourage callers from peeking into
these trailer-internal fields.

Patches 2-3 aim to make some functions do a little less multitasking.

Patch 4 makes the find_patch_start function care about the "--no-divider"
option, because it that option matters for determining the start of the
"patch part" of the input.

Patch 5 is a renaming change to reduce overloaded language in the codebase.
It is inspired by 229d6ab (doc: trailer: examples: avoid the word
"message" by itself, 2023-06-15) [4], which did a similar thing for the
interpret-trailers documentation.

[1]
https://lore.kernel.org/git/pull.1564.git.1691210737.gitgitgadget@gmail.com/T/#mb044012670663d8eb7a548924bbcc933bef116de
[2]
https://lore.kernel.org/git/20230627195251.1973421-1-calvinwan@google.com/
[3]
https://lore.kernel.org/git/pull.1149.git.1677143700.gitgitgadget@gmail.com/
[4]
https://lore.kernel.org/git/6b4cb31b17077181a311ca87e82464a1e2ad67dd.1686797630.git.gitgitgadget@gmail.com/

Linus Arver (5):
  trailer: separate public from internal portion of trailer_iterator
  trailer: split process_input_file into separate pieces
  trailer: split process_command_line_args into separate functions
  trailer: teach find_patch_start about --no-divider
  trailer: rename *_DEFAULT enums to *_UNSPECIFIED

 trailer.c | 113 ++++++++++++++++++++++++++++++------------------------
 trailer.h |  12 +++---
 2 files changed, 69 insertions(+), 56 deletions(-)

base-commit: 1b0a512

Submitted-As: https://lore.kernel.org/git/pull.1563.git.1691211879.gitgitgadget@gmail.com

Git 2.42-rc0

git bisect visualize: find gitk on Windows again

Louis Strous reported a regression in git bisect visualize on Windows[1]
that caused git bisect visualize to use git log instead of gitk unless
explicitly called as git bisect visualize gitk. It was introduced during the
conversion of git bisect visualize to a builtin.

This patch series fixes that regression.

Changes since v1:

 * simplified patches 1 and 2 based on Junios feedback.
 * expanded the new wording in the documentation to clarify which variables
   users might encounter

[1]
https://lore.kernel.org/git/VI1PR10MB2462F7B52FF2E3F59AFE94A7F500A@VI1PR10MB2462.EURPRD10.PROD.OUTLOOK.COM/

Matthias Aßhauer (3):
  run-command: conditionally define locate_in_PATH()
  compat/mingw: implement a native locate_in_PATH()
  docs: update when `git bisect visualize` uses `gitk`

 Documentation/git-bisect.txt | 11 ++++++++---
 compat/mingw.c               |  5 +++++
 compat/mingw.h               |  3 +++
 run-command.c                |  2 ++
 4 files changed, 18 insertions(+), 3 deletions(-)

base-commit: fb7d80e

Submitted-As: https://lore.kernel.org/git/pull.1560.v2.git.1691122124.gitgitgadget@gmail.com
In-Reply-To: https://lore.kernel.org/git/pull.1560.git.1691058498.gitgitgadget@gmail.com

rebase --skip: fix commit message clean up when skipping squash

From: Phillip Wood <phillip.wood@dunelm.org.uk>

During a series of "fixup" and/or "squash" commands, the interactive
rebase accumulates a commit message from all the commits that are being
squashed together. If one of the commits has conflicts when it is picked
and the user chooses to skip that commit then we need to remove that
commit's message from accumulated messages.  To do this 15ef693
(rebase --skip: clean up commit message after a failed fixup/squash,
2018-04-27) updated commit_staged_changes() to reset the accumulated
message to the commit message of HEAD (which does not contain the
message from the skipped commit) when the last command was "fixup" or
"squash" and there are no staged changes. Unfortunately the code to do
this contains two bugs.

(1) If parse_head() fails we pass an invalid pointer to
    unuse_commit_buffer().

(2) The reconstructed message uses the entire commit buffer from HEAD
    including the headers, rather than just the commit message.

The fist issue is fixed by splitting up the "if" condition into several
statements each with its own error handling. The second issue is fixed
by finding the start of the commit message within the commit buffer
using find_commit_subject().

The existing test added by 15ef693 is modified to show the effect of
this bug.  The bug is triggered when skipping the first command in the
chain (as the test does before this commit) but the effect is hidden
because opts->current_fixup_count is set to zero which leads
update_squash_messages() to recreate the squash message file from
scratch overwriting the bad message created by
commit_staged_changes(). The test is also updated to explicitly check
the commit messages rather than relying on grep to ensure they do not
contain any stay commit headers.

To check the commit message the function test_commit_message() is moved
from t3437-rebase-fixup-options.sh to test-lib.sh. As the function is
now publicly available it is updated to provide better error detection
and avoid overwriting the commonly used files "actual" and "expect".
Support for reading the expected commit message from stdin is also
added.

Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>

Submitted-As: https://lore.kernel.org/git/pull.1558.git.git.1691068176051.gitgitgadget@gmail.com

git bisect visualize: find gitk on Windows again

Louis Strous reported a regression in git bisect visualize on Windows[1]
that caused git bisect visualize to use git log instead of gitk unless
explicitly called as git bisect visualize gitk.

This patch series fixes that regression.

[1]
https://lore.kernel.org/git/VI1PR10MB2462F7B52FF2E3F59AFE94A7F500A@VI1PR10MB2462.EURPRD10.PROD.OUTLOOK.COM/

Matthias Aßhauer (3):
  compat: make path_lookup() available outside mingw.c
  run-command: teach locate_in_PATH about Windows
  docs: update when `git bisect visualize` uses `gitk`

 Documentation/git-bisect.txt |  6 +++---
 compat/mingw.c               | 20 ++++++++------------
 compat/mingw.h               |  6 ++++++
 run-command.c                |  8 ++++----
 4 files changed, 21 insertions(+), 19 deletions(-)

base-commit: fb7d80e

Submitted-As: https://lore.kernel.org/git/pull.1560.git.1691058498.gitgitgadget@gmail.com