summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorLines
2026-02-13Merge branch 'tc/last-modified-not-a-tree'Junio C Hamano-11/+34
Giving "git last-modified" a tree (not a commit-ish) died an uncontrolled death, which has been corrected. * tc/last-modified-not-a-tree: last-modified: verify revision argument is a commit-ish last-modified: remove double error message last-modified: fix memory leak when more than one commit is given last-modified: rewrite error message when more than one commit given
2026-02-13Merge branch 'mc/doc-send-email-signed-off-by-cc'Junio C Hamano-1/+1
Docfix. * mc/doc-send-email-signed-off-by-cc: doc: send-email: correct --no-signed-off-by-cc misspelling
2026-02-13Merge branch 'cf/c23-const-preserving-strchr-updates-0'Junio C Hamano-31/+34
ISO C23 redefines strchr and friends that tradiotionally took a const pointer and returned a non-const pointer derived from it to preserve constness (i.e., if you ask for a substring in a const string, you get a const pointer to the substring). Update code paths that used non-const pointer to receive their results that did not have to be non-const to adjust. * cf/c23-const-preserving-strchr-updates-0: gpg-interface: remove an unnecessary NULL initialization global: constify some pointers that are not written to
2026-02-13Merge branch 'jc/diff-highlight-main-master-testfix'Junio C Hamano-0/+2
Test fix (in contrib/) * jc/diff-highlight-main-master-testfix: diff-highlight: allow testing with Git 3.0 breaking changes
2026-02-13Merge branch 'cs/subtree-reftable-testfix'Junio C Hamano-4/+3
Test fix (in contrib/) * cs/subtree-reftable-testfix: contrib/subtree: fix tests with reftable backend
2026-02-13Merge branch 'tc/memzero-array'Junio C Hamano-9/+33
Coccinelle rules update. * tc/memzero-array: cocci: extend MEMZERO_ARRAY() rules
2026-02-13t0213: add trace2 cmd_ancestry testsMatthew John Cheetham-2/+184
Add a new test script t0213-trace2-ancestry.sh that verifies cmd_ancestry events across all three trace2 output formats (normal, perf, and event). The tests use the "400ancestry" test helper to spawn child processes with controlled trace2 environments. Git alias resolution (which spawns a child git process) creates a predictable multi-level process tree. Filter functions extract cmd_ancestry events from each format, truncating the ancestor list at the outermost "test-tool" so that only the controlled portion of the tree is verified, regardless of the test runner environment. A runtime prerequisite (TRACE2_ANCESTRY) is used to detect whether the platform has a real procinfo implementation; platforms with only the stub are skipped. We must pay attention to an extra ancestor on Windows (MINGW) when running without the bin-wrappers (such as we do in CI). In this situation we see an extra "sh.exe" ancestor after "test-tool.exe". Also update the comment in t0210-trace2-normal.sh to reflect that ancestry testing now has its own dedicated test script. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13test-tool: extend trace2 helper with 400ancestryMatthew John Cheetham-0/+59
Add a new test helper "400ancestry" to the trace2 test-tool that spawns a child process with a controlled trace2 environment, capturing only the child's trace2 output (including cmd_ancestry events) in isolation. The helper clears all inherited GIT_TRACE2* variables in the child and enables only the requested target (normal, perf, or event), directing output to a specified file. This gives the test suite a reliable way to capture cmd_ancestry events: the child always sees "test-tool" as its immediate parent in the process ancestry, providing a predictable value to verify in tests. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13trace2: emit cmd_ancestry data for WindowsMatthew John Cheetham-0/+8
Since 2f732bf15e (tr2: log parent process name, 2021-07-21) it is now now possible to emit a specific process ancestry event in TRACE2. We should emit the Windows process ancestry data with the correct event type. To not break existing consumers of the data_json "windows/ancestry" event, we continue to emit the ancestry data as a JSON event. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13trace2: refactor Windows process ancestry trace2 eventMatthew John Cheetham-25/+25
In 353d3d77f4 (trace2: collect Windows-specific process information, 2019-02-22) we added process ancestry information for Windows to TRACE2 via a data_json event. It was only later in 2f732bf15e (tr2: log parent process name, 2021-07-21) that the specific cmd_ancestry event was added to TRACE2. In a future commit we will emit the ancestry information with the newer cmd_ancestry TRACE2 event. Right now, we rework this implementation of trace2_collect_process_info to separate the calculation of ancestors from building and emiting the JSON array via a data_json event. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13build: include procinfo.c impl for macOSMatthew John Cheetham-0/+6
Include an implementation of trace2_collect_process_info for macOS. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13trace2: add macOS process ancestry tracingMatthew John Cheetham-0/+97
In 353d3d77f4 (trace2: collect Windows-specific process information, 2019-02-22) Windows-specific process ancestry information was added as a data_json event to TRACE2. Furthermore in 2f732bf15e (tr2: log parent process name, 2021-07-21) similar functionality was added for Linux-based systems, using procfs. Teach Git to also log process ancestry on macOS using the sysctl with KERN_PROC to get process information (PPID and process name). Like the Linux implementation, we use the cmd_ancestry TRACE2 event rather than using a data_json event and creating another custom data point. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13templates: detect commit messages containing diffsPhillip Wood-2/+52
If the body of a commit message contains a diff that is not indented then "git am" will treat that diff as part of the patch rather than as part of the commit message. This allows it to apply email messages that were created by adding a commit message in front of a regular diff without adding the "---" separator used by "git format-patch". This often surprises users [1-4] so add a check to the sample "commit-msg" hook to reject messages that would confuse "git am". Even if a project does not use an email based workflow it is not uncommon for people to generate patches from it and apply them with "git am". Therefore it is still worth discouraging the creation of commit messages that would not be applied correctly. A further source of confusion when applying patches with "git am" is the "---" separator that is added by "git format patch". If a commit message body contains that line then it will be truncated by "git am". As this is often used by patch authors to add some commentary that they do not want to end up in the commit message when the patch is applied, the hook does not complain about the presence of "---" lines in the message. Detecting if the message contains a diff is complicated by the hook being passed the message before it is cleaned up so we need to ignore any diffs below the scissors line. There are also two possible config keys to check to find the comment character at the start of the scissors line. The first paragraph of the commit message becomes the email subject header which beings "Subject: " and so does not need to be checked. The trailing ".*" when matching commented lines ensures that if the comment string ends with a "$" it is not treated as an anchor. [1] https://lore.kernel.org/git/bcqvh7ahjjgzpgxwnr4kh3hfkksfruf54refyry3ha7qk7dldf@fij5calmscvm [2] https://lore.kernel.org/git/ca13705ae4817ffba16f97530637411b59c9eb19.camel@scientia.org/ [3] https://lore.kernel.org/git/d0b577825124ac684ab304d3a1395f3d2d0708e8.1662333027.git.matheus.bernardino@usp.br/ [4] https://lore.kernel.org/git/CAFOYHZC6Qd9wkoWPcTJDxAs9u=FGpHQTkjE-guhwkya0DRVA6g@mail.gmail.com/ Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-13templates: add .gitattributes entry for sample hooksPhillip Wood-1/+2
The sample hooks are shell scripts but the filenames end with ".sample" so they need their own .gitattributes rule. Update our editorconfig settings to match the attributes as well. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12sparse-checkout: use string_list_sort_uAmisha Chhajed-2/+1
sparse_checkout_list() uses string_list_sort and string_list_remove_duplicates instead of string_list_sort_u. use string_list_sort_u at that place. Signed-off-by: Amisha Chhajed <136238836+amishhaa@users.noreply.github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12doc: add caveat about round-tripping format-patchKristoffer Haugsbakk-7/+62
git-format-patch(1) and git-am(1) deal with formatting commits as patches and applying them, respectively. Naturally they use a few delimiters to mark where the commit message ends. This can lead to surprising behavior when these delimiters are used in the commit message itself. git-format-patch(1) will accept any commit message and not warn or error about these delimiters being used.[1] Especially problematic is the presence of unindented diffs in the commit message; the patch machinery will naturally (since the commit message has ended) try to apply that diff and everything after it.[2] It is unclear whether any commands in this chain will learn to warn about this. One concern could be that users have learned to rely on the three-dash line rule to conveniently add extra-commit message information in the commit message, knowing that git-am(1) will ignore it.[4] All of this is covered already, technically. However, we should spell out the implications. † 1: There is also git-commit(1) to consider. However, making that command warn or error out over such delimiters would be disruptive to all Git users who never use email in their workflow. † 2: Recently patch(1) caused this issue for a project, but it was noted that git-am(1) has the same behavior[3] † 3: https://github.com/i3/i3/pull/6564#issuecomment-3858381425 † 4: https://lore.kernel.org/git/xmqqldh4b5y2.fsf@gitster.g/ https://lore.kernel.org/git/V3_format-patch_caveats.354@msgid.xyz/ Reported-by: Matthias Beyer <mail@beyermatthias.de> Reported-by: Christoph Anton Mitterer <calestyo@scientia.org> Reported-by: Matheus Tavares <matheus.tavb@gmail.com> Reported-by: Chris Packham <judge.packham@gmail.com> Helped-by: Jakob Haufe <sur5r@sur5r.net> Helped-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12t9812: modernize test path helpersAshwani Kumar Kamal-4/+4
Replace assertion-style 'test -f' checks with Git's test_path_is_file() helper for clearer failures and consistency. Signed-off-by: Ashwani Kumar Kamal <ashwanikamal.im421@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12odb: convert `odb_has_object()` flags into an enumPatrick Steinhardt-3/+3
Following the reason in the preceding commit, convert the `odb_has_object()` flags into an enum. With this change, we would have catched the misuse of `odb_has_object()` that was fixed in a preceding commit as the compiler would have generated a warning: ../builtin/backfill.c:71:9: error: implicit conversion from enumeration type 'enum odb_object_info_flag' to different enumeration type 'enum odb_has_object_flag' [-Werror,-Wenum-conversion] 70 | if (!odb_has_object(ctx->repo->objects, &list->oid[i], | ~~~~~~~~~~~~~~ 71 | OBJECT_INFO_FOR_PREFETCH)) | ^~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12odb: convert object info flags into an enumPatrick Steinhardt-22/+30
Convert the object info flags into an enum and adapt all functions that receive these flags as parameters to use the enum instead of an integer. This serves two purposes: - The function signatures become more self-documenting, as callers don't have to wonder which flags they expect. - The compiler can warn when a wrong flag type is passed. Note that the second benefit is somewhat limited. For example, when or-ing multiple enum flags together the result will be an integer, and the compiler will not warn about such use cases. But where it does help is when a single flag of the wrong type is passed, as the compiler would generate a warning in that case. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12odb: drop gaps in object info flag valuesPatrick Steinhardt-4/+4
The object info flag values have a two gaps in their definitions, where some bits are skipped over. These gaps don't really hurt, but it makes one wonder whether anything is going on and whether a subset of flags might be defined somewhere else. That's not the case though. Instead, this is a case of flags that have been dropped in the past: - The value 4 was used by `OBJECT_INFO_SKIP_CACHED`, removed in 9c8a294a1a (sha1-file: remove OBJECT_INFO_SKIP_CACHED, 2020-01-02). - The value 8 was used by `OBJECT_INFO_ALLOW_UNKNOWN_TYPE`, removed in ae24b032a0 (object-file: drop OBJECT_INFO_ALLOW_UNKNOWN_TYPE flag, 2025-05-16). Close those gaps to avoid any more confusion. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12builtin/fsck: fix flags passed to `odb_has_object()`Patrick Steinhardt-1/+2
In `mark_object()` we invoke `has_object()` with a value of 1. This is somewhat fishy given that the function expects a bitset of flags, so any behaviour that this results in is purely coincidental and may break at any point in time. The call to `has_object()` was originally introduced in 9eb86f41de (fsck: do not lazy fetch known non-promisor object, 2020-08-05). The intent here was to skip lazy fetches of promisor objects: we have already verified that the object is not a promisor object, so if the object is missing it indicates a corrupt repository. The hardcoded value that we pass maps to `HAS_OBJECT_RECHECK_PACKED`, which is probably the intended behaviour: `odb_has_object()` will not fetch promisor objects unless `HAS_OBJECT_FETCH_PROMISOR` is passed, but we may want to verify that no concurrent process has written the object that we're trying to read. Convert the code to use the named flag instead of the the hardcoded value. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12builtin/backfill: fix flags passed to `odb_has_object()`Patrick Steinhardt-2/+1
The function `fill_missing_blobs()` receives an array of object IDs and verifies for each of them whether the corresponding object exists. If it doesn't exist, we add it to a set of objects and then batch-fetch all of the objects at once. The check for whether or not we already have the object is broken though: we pass `OBJECT_INFO_FOR_PREFETCH`, but `odb_has_object()` expects us to pass `HAS_OBJECT_*` flags. The flag expands to: - `OBJECT_INFO_QUICK`, which asks the object database to not reprepare in case the object wasn't found. This makes sense, as we'd otherwise reprepare the object database as many times as we have missing objects. - `OBJECT_INFO_SKIP_FETCH_OBJECT`, which asks the object database to not fetch the object in case it's missing. Again, this makes sense, as we want to batch-fetch the objects. This shows that we indeed want the equivalent of this flag, but of course represented as `HAS_OBJECT_*` flags. Luckily, the code is already working correctly. The `OBJECT_INFO` flag expands to `(1 << 3) | (1 << 4)`, none of which are valid `HAS_OBJECT` flags. And if no flags are passed, `odb_has_object()` ends up calling `odb_read_object_info_extended()` with exactly the above two flags that we wanted to set in the first place. Of course, this is pure luck, and this can break any moment. So let's fix this and correct the code to not pass any flags at all. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-12diff --anchored: avoid checking unmatched linesPhillip Wood-12/+6
For a line to be an anchor it has to appear in each of the files being diffed exactly once. With that in mind lets delay checking whether a line is an anchor until we know there is exactly one instance of the line in each file. As each line is checked at most once, there is no need to cache the result of is_anchor() and we can drop that field from the hashmap entries. When diffing 5000 recent commits in git.git this gives a modest speedup of ~2%. In the (rather extreme) example below that consists largely of deletions the speedup is ~16%. seq 0 10000000 >old printf '%s\n' 300000 100000 200000 >new git diff --no-index --anchored=300000 old new Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-11Merge branch 'master' of https://github.com/j6t/gitkJunio C Hamano-2/+2
* 'master' of https://github.com/j6t/gitk: gitk: fix msgfmt being required gitk: fix highlighted remote prefix of branches with directories
2026-02-11CodingGuidelines: document // commentsJunio C Hamano-0/+2
We do not use // comments in our C code, which is implied by the description of multi-line comment rule and its examples, but is not explicitly spelled out. Spell it out. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-11The 3rd batchJunio C Hamano-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-11Merge branch 'rs/blame-ignore-colors-fix'Junio C Hamano-4/+23
"git blame --ignore-revs=... --color-lines" did not account for ignored revisions passing blame to the same commit an adjacent line gets blamed for. * rs/blame-ignore-colors-fix: blame: fix coloring for repeated suspects
2026-02-11Merge branch 'hs/t9160-test-paths'Junio C Hamano-13/+13
Test update. * hs/t9160-test-paths: t9160:modernize test path checking
2026-02-11Merge branch 'am/doc-github-contributiong-link-to-submittingpatches'Junio C Hamano-1/+2
GitHub repository banner update. * am/doc-github-contributiong-link-to-submittingpatches: .github/CONTRIBUTING.md: link to SubmittingPatches on git-scm.com
2026-02-11Merge branch 'kh/doc-shortlog-fix'Junio C Hamano-3/+4
Doc fix. * kh/doc-shortlog-fix: doc: shortlog: put back trailer paragraphs
2026-02-11Merge branch 'sp/show-index-warn-fallback'Junio C Hamano-14/+17
When "git show-index" is run outside a repository, it silently defaults to SHA-1; the tool now warns when this happens. * sp/show-index-warn-fallback: show-index: use gettext wrapping in user facing error messages show-index: warn when falling back to SHA-1 outside a repository
2026-02-11builtin/pack-objects: don't fetch objects when merging packsPatrick Steinhardt-0/+28
The "--stdin-packs" option can be used to merge objects from multiple packfiles given via stdin into a new packfile. One big upside of this option is that we don't have to perform a complete rev walk to enumerate objects. Instead, we can simply enumerate all objects that are part of the specified packfiles, which can be significantly faster in very large repositories. There is one downside though: when we don't perform a rev walk we also don't have a good way to learn about the respective object's names. As a consequence, we cannot use the name hashes as a heuristic to get better delta selection. We try to offset this downside though by performing a localized rev walk: we queue all objects that we're about to repack as interesting, and all objects from excluded packfiles as uninteresting. We then perform a best-effort rev walk that allows us to fill in object names. There is one gotcha here though: when "--exclude-promisor-objects" has not been given we will perform backfill fetches for any promised objects that are missing. This used to not be an issue though as this option was mutually exclusive with "--stdin-packs". But that has changed recently, and starting with dcc9c7ef47 (builtin/repack: handle promisor packs with geometric repacking, 2026-01-05) we will now repack promisor packs during geometric compaction. The consequence is that a geometric repack may now perform a bunch of backfill fetches. We of course cannot pass "--exclude-promisor-objects" to fix this issue -- after all, the whole intent is to repack objects part of a promisor pack. But arguably we don't have to: the rev walk is intended as best effort, and we already configure it to ignore missing links to other objects. So we can adapt the walk to unconditionally disable fetching any missing objects. Do so and add a test that verifies we don't backfill any objects. Reported-by: Lukas Wanko <lwanko@gitlab.com> Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-10doc: rerere-options.adoc: link to git-rerere(1)Kristoffer Haugsbakk-2/+2
Five commands include these options. Let’s link to the command so that the curious user can learn more about what “rerere” is about. It’s also better to consistently refer to things like e.g. “git-subcommand(1)” over `git subcommand` or `subcommand`. Also apply the same treatment to git-add(1). Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-10xdiff-interface: stop using the_repositoryRené Scharfe-18/+21
Use the algorithm-agnostic is_null_oid() and push the dependency of read_mmblob() on the_repository->objects to its callers. This allows it to be used with arbitrary object databases. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09The second batchJunio C Hamano-0/+21
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09Merge branch 'ty/perf-3400-optim'Junio C Hamano-15/+38
Improve set-up time of a perf test. * ty/perf-3400-optim: t/perf/p3400: speed up setup using fast-import
2026-02-09Merge branch 'ac/string-list-sort-u-and-tests'Junio C Hamano-16/+263
The string_list API gains a new helper, string_list_sort_u(), and new unit tests to extend coverage. * ac/string-list-sort-u-and-tests: string-list: add string_list_sort_u() that mimics "sort -u" u-string-list: add unit tests for string-list methods
2026-02-09Merge branch 'sb/doc-worktree-prune-expire-improvement'Junio C Hamano-4/+10
The help text and the documentation for the "--expire" option of "git worktree [list|prune]" have been improved. * sb/doc-worktree-prune-expire-improvement: worktree: clarify that --expire only affects missing worktrees
2026-02-09Merge branch 'kn/ref-batch-output-error-reporting-fix'Junio C Hamano-125/+312
A handful of code paths that started using batched ref update API (after Git 2.51 or so) lost detailed error output, which have been corrected. * kn/ref-batch-output-error-reporting-fix: fetch: delay user information post committing of transaction receive-pack: utilize rejected ref error details fetch: utilize rejected ref error details update-ref: utilize rejected error details if available refs: add rejection detail to the callback function refs: skip to next ref when current ref is rejected
2026-02-09Merge branch 'pw/replay-drop-empty'Junio C Hamano-4/+31
"git replay" is taught to drop commits that become empty (not the ones that are empty in the original). * pw/replay-drop-empty: replay: drop commits that become empty
2026-02-09Merge branch 'ps/history'Junio C Hamano-341/+1425
"git history" history rewriting UI. * ps/history: builtin/history: implement "reword" subcommand builtin: add new "history" command wt-status: provide function to expose status for trees replay: support updating detached HEAD replay: support empty commit ranges replay: small set of cleanups builtin/replay: move core logic into "libgit.a" builtin/replay: extract core logic to replay revisions
2026-02-09rerere: minor documantation updateJunio C Hamano-2/+2
Let's not call our users "it". Also "rerere forget \*.c" does not forget resolutions for just '*.c'; it forgets for all the files whose filenames end with ".c". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09doc: am: fill out hook discussionKristoffer Haugsbakk-4/+9
Document `--verify` and rephrase the `--[no-]verify` section to lead with the default, in imperative mood.[1] Historically it makes sense that only the negated forms are documented; they are all run by default and thus you only need to use hook options if you want to turn some of them off. But, beyond just desiring uniform documentation,[2] it’s very much possible to have, say, a Git alias with `--no-verify` that you might sometimes want to turn back on with the *positive* form. Also mention the options in the “Hooks” section and mention that `post-applypatch` cannot be skipped. † 1: See e.g. acffc5e9 (doc: convert git-remote to synopsis style, 2025-12-20) † 2: https://lore.kernel.org/git/xmqqcyct1mtq.fsf@gitster.g/ Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09doc: am: add missing config am.messageIdKristoffer Haugsbakk-0/+6
Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09doc: am: say that --message-id adds a trailerKristoffer Haugsbakk-7/+9
The option `--message-id` was added in a078f732 (git-am: add --message-id/--no-message-id, 2014-11-25) back when git-interpret- trailers(1) was relatively new. Let’s spell out that it is a trailer and link to the dedicated trailer command. Also use inline-verbatim for `Message-ID`. Also link to git-interpret-trailers(1) on `--signoff`. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09doc: am: normalize git(1) command linksKristoffer Haugsbakk-25/+24
There are many mentions of commands using inline-verbatim or emphasis ('). We just mention the command themselves, not specific invocations like `git am <opts>`. Let’s link to them instead. There are also many such mentions which then link to the command right afterwards. Simplify to just using a link. Also remove “see <gitlink>” phrases where they have now already been mentioned. Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09t7003: modernize path existence checks using test helpersSoutrikDas-6/+6
Replace direct uses of 'test -f' and 'test -d' with git's helper functions 'test_path_is_file' , 'test_path_is_missing' and 'test_path_is_dir' Signed-off-by: SoutrikDas <valusoutrik@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09t2003: modernize path existence checks using test helpersBurak Kaan Karaçay-25/+25
The old style 'test -f' and 'test -d' checks are silent on failure, which makes debugging difficult. Replace them with the 'test_path_is_*' helpers which provide verbose error messages when a test fails. Signed-off-by: Burak Kaan Karaçay <bkkaracay@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09meson: fix building mergetool docsPhillip Wood-4/+1
Building the documentation with meson when the build directory is not an immediate subdirectory of the source directory prints the following error [2/1349] Generating Documentation/mer... command (wrapped by meson to set env) ../../Documentation/generate-mergetool-list.sh: line 15: ../git-mergetool--lib.sh: No such file or directory The build does not fail because the failure is upstream of a pipe. Fix the error by passing the correct source directory when meson runs "generate-mergetool-list.sh". As that script sets $MERGE_TOOLS_DIR we do not need to set it in the environment when running the script. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2026-02-09checkout: tell "parse_remote_branch" which command is calling itJunio C Hamano-5/+42
When "git checkout <dwim>" and "git switch <dwim>" need to error out due to ambiguity of the branch name <dwim>, these two commands give an advise message with a sample command that tells the user how to disambiguate from the parse_remote_branch() function. The sample command hardcodes "git checkout", since this feature predates "git switch" by a large margin. To a user who said "git switch <dwim>" and got this message, it is confusing. Pass the "enum checkout_command", which was invented in the previous step for this exact purpose, down the call chain leading to parse_remote_branch() function to change the sample command shown to the user in this advise message. Also add a bit more test coverage for this "fail to DWIM under ambiguity" that we lack, as well as the message we produce when we fail. Reported-by: Simon Cheng <cyqsimon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>