summaryrefslogtreecommitdiffstats
path: root/promisor-remote.h (unfollow)
Commit message (Collapse)AuthorFilesLines
2023-10-09documentation: fix subject/verb agreementElijah Newren25-28/+28
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: remove extraneous wordsElijah Newren15-15/+15
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: add missing wordsElijah Newren19-19/+19
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: fix apostrophe usageElijah Newren8-8/+8
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: fix typosElijah Newren9-11/+11
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: fix small errorElijah Newren1-1/+1
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-09documentation: wording improvementsElijah Newren74-133/+134
Diff best viewed with --color-diff. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-04The fifteenth batchJunio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-10-02The fourteenth batchJunio C Hamano1-0/+5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-29The thirteenth batchJunio C Hamano1-5/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28doc: correct the 50 characters soft limit谢致邦 (XIE Zhibang)1-1/+1
The soft limit of the first line of the commit message should be "no more than 50 characters" or "50 characters or less", but not "less than 50 character". Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: report incomplete chains during verificationJeff King4-7/+45
The load_commit_graph_chain_fd_st() function will stop loading chains when it sees an error. But if it has loaded any graph slice at all, it will return it. This is a good thing for normal use (we use what data we can, and this is just an optimization). But it's a bad thing for "commit-graph verify", which should be careful about finding any irregularities. We do complain to stderr with a warning(), but the verify command still exits with a successful return code. The new tests here cover corruption of both the base and tip slices of the chain. The corruption of the base file already works (it is the first file we look at, so when we see the error we return NULL). The "tip" case is what is fixed by this patch (it complains to stderr but still returns the base slice). Likewise the existing tests for corruption of the commit-graph-chain file itself need to be updated. We already exited non-zero correctly for the "base" case, but the "tip" case can now do so, too. Note that this also causes us to adjust a test later in the file that similarly corrupts a tip (though confusingly the test script calls this "base"). It checks stderr but erroneously expects the whole "verify" command to exit with a successful code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: tighten chain size checkJeff King2-2/+20
When we open a commit-graph-chain file, if it's smaller than a single entry, we just quietly treat that as ENOENT. That make some sense if the file is truly zero bytes, but it means that "commit-graph verify" will quietly ignore a file that contains garbage if that garbage happens to be short. Instead, let's only simulate ENOENT when the file is truly empty, and otherwise return EINVAL. The normal graph-loading routines don't care, but "commit-graph verify" will notice and complain about the difference. It's not entirely clear to me that the 0-is-ENOENT case actually happens in real life, so we could perhaps just eliminate this special-case altogether. But this is how we've always behaved, so I'm preserving it in the name of backwards compatibility (though again, it really only matters for "verify", as the regular routines are happy to load what they can). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: detect read errors when verifying graph chainJeff King2-9/+18
Because it's OK to not have a graph file at all, the graph_verify() function needs to tell the difference between a missing file and a real error. So when loading a traditional graph file, we call open_commit_graph() separately from load_commit_graph_chain_fd_st(), and don't complain if the first one fails with ENOENT. When the function learned about chain files in 3da4b609bb (commit-graph: verify chains with --shallow mode, 2019-06-18), we couldn't be as careful, since the only way to load a chain was with read_commit_graph_one(), which did both the open/load as a single unit. So we'll miss errors in chain files we load, thinking instead that there was just no chain file at all. Note that we do still report some of these problems to stderr, as the loading function calls error() and warning(). But we'd exit with a successful exit code, which is wrong. We can fix that by using the recently split open/load functions for chains. That lets us treat the chain file just like a single file with respect to error handling here. An existing test (from 3da4b609bb) shows off the problem; we were expecting "commit-graph verify" to report success, but that makes no sense. We did not even verify the contents of the graph data, because we couldn't load it! I don't think this was an intentional exception, but rather just the test covering what happened to occur. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28t5324: harmonize sha1/sha256 graph chain corruptionJeff King1-5/+20
In t5324.20, we corrupt a hex character 60 bytes into the graph chain file. Since the file consists of two hash identifiers, one per line, the corruption differs between sha1 and sha256. In a sha1 repository, the corruption is on the second line, and in a sha256 repository, it is on the first. We should of course detect the problem with either line. But as the next few patches will show (and fix), that is not the case (in fact, we currently do not exit non-zero for either line!). And while at the end of our series we'll catch all errors, our intermediate states will have differing behavior between the two hashes. Let's make sure we test corruption of both the first and second lines, and do so consistently with either hash by choosing offsets which are always in the first hash (30 bytes) or in the second (70). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: check mixed generation validation when loading chain fileJeff King1-27/+27
In read_commit_graph_one(), we call validate_mixed_generation_chain() after loading the graph. Even though we don't check the return value, this has the side effect of clearing the read_generation_data flag, which is important when working with mixed generation numbers. But doing this in load_commit_graph_chain_fd_st() makes more sense: 1. We are calling it even when we did not load a chain at all, which is pointless (you cannot have mixed generations in a single file). 2. For now, all callers load the graph via read_commit_graph_one(). But the point of factoring out the open/load in the previous commit was to let "commit-graph verify" call them separately. So it needs to trigger this function as part of the load. Without this patch, the mixed-generation tests in t5324 would start failing on "git commit-graph verify" calls, once we switch to using a separate open/load call there. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-28commit-graph: factor out chain opening functionJeff King2-19/+42
The load_commit_graph_chain() function opens the chain file and all of the slices of graph that it points to. If there is no chain file (which is a totally normal condition), we return NULL. But if we run into errors with the chain file or loading the actual graph data, we also return NULL, and the caller cannot tell the difference. The caller can check for ENOENT for the unremarkable "no such file" case. But I'm hesitant to assume that the rest of the function would never accidentally set errno to ENOENT itself, since it is opening the slice files (and that would mean the caller fails to notice a real error). So let's break this into two functions: one to open the file, and one to actually load it. This matches the interface we provide for the non-chain graph file, which will also come in handy in a moment when we fix some bugs in the "git commit-graph verify" code. Some notes: - I've kept the "1 is good, 0 is bad" return convention (and the weird "fd" out-parameter) used by the matching open_commit_graph() function and other parts of the commit-graph code. This is unlike most of the rest of Git (which would just return the fd, with -1 for error), but it makes sense to stay consistent with the adjacent bits of the API here. - The existing chain loading function will quietly return if the file is too small to hold a single entry. I've retained that behavior (and explicitly set ENOENT in the opener function) for now, under the notion that it's probably valid (though I'd imagine unusual) to have an empty chain file. There are two small behavior changes here, but I think both are strictly positive: 1. The original blindly did a stat() before checking if fopen() succeeded, meaning we were making a pointless extra stat call. 2. We now use fstat() to check the file size. The previous code using a regular stat() on the pathname meant we could technically race with somebody updating the chain file, and end up with a size that does not match what we just opened with fopen(). I doubt anybody ever hit this in practice, but it may have caused an out-of-bounds read. We'll retain the load_commit_graph_chain() function which does both the open and reading steps (most existing callers do not care about seeing errors anyway, since loading commit-graphs is optimistic). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-26unicode: update the width tables to Unicode 15.1Beat Bolli1-3/+2
Unicode 15.1 has been announced on 2023-09-12 [0], so update the character width tables to the new version. [0] http://blog.unicode.org/2023/09/announcing-unicode-standard-version-151.html Signed-off-by: Beat Bolli <dev+git@drbeat.li> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-25ref-filter: add mailmap supportKousik Sanagavarapu3-37/+206
Add mailmap support to ref-filter formats which are similar in pretty. This support is such that the following pretty placeholders are equivalent to the new ref-filter atoms: %aN = authorname:mailmap %cN = committername:mailmap %aE = authoremail:mailmap %aL = authoremail:mailmap,localpart %cE = committeremail:mailmap %cL = committeremail:mailmap,localpart Additionally, mailmap can also be used with ":trim" option for email by doing something like "authoremail:mailmap,trim". The above also applies for the "tagger" atom, that is, "taggername:mailmap", "taggeremail:mailmap", "taggeremail:mailmap,trim" and "taggername:mailmap,localpart". The functionality of ":trim" and ":localpart" remains the same. That is, ":trim" gives the email, but without the angle brackets and ":localpart" gives the part of the email before the '@' character (if such a character is not found then we directly grab everything between the angle brackets). Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-25t/t6300: introduce test_bad_atomKousik Sanagavarapu1-0/+24
Introduce a new function "test_bad_atom", which is similar to "test_atom()" but should be used to check whether the correct error message is shown on stderr. Like "test_atom", the new function takes three arguments. The three arguments specify the ref, the format and the expected error message respectively, with an optional fourth argument for tweaking "test_expect_*" (which is by default "success"). Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-25t/t6300: cleanup test_atomKousik Sanagavarapu1-6/+10
Previously, when the executable part of "test_expect_{success,failure}" (inside "test_atom") got "eval"ed, it would have been syntactically incorrect if the second argument ($2, which is the format) to "test_atom" were enclosed in single quotes because the $variables would get interpolated even before the arguments to "test_expect_{success,failure}" are formed. So fix this and also some style issues along the way. Helped-by: Junio C Hamano <gitster@pobox.com> Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: Kousik Sanagavarapu <five231003@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-25revision: make pseudo-opt flags read via stdin behave consistentlyPatrick Steinhardt3-6/+33
When reading revisions from stdin via git-rev-list(1)'s `--stdin` option then these revisions never honor flags like `--not` which have been passed on the command line. Thus, an invocation like e.g. `git rev-list --all --not --stdin` will not treat all revisions read from stdin as uninteresting. While this behaviour may be surprising to a user, it's been this way ever since it has been introduced via 42cabc341c4 (Teach rev-list an option to read revs from the standard input., 2006-09-05). With that said, in c40f0b7877 (revision: handle pseudo-opts in `--stdin` mode, 2023-06-15) we have introduced a new mode to read pseudo opts from standard input where this behaviour is a lot more confusing. If you pass `--not` via stdin, it will: - Influence subsequent revisions or pseudo-options passed on the command line. - Influence pseudo-options passed via standard input. - _Not_ influence normal revisions passed via standard input. This behaviour is extremely inconsistent and bound to cause confusion. While it would be nice to retroactively change the behaviour for how `--not` and `--stdin` behave together, chances are quite high that this would break existing scripts that expect the current behaviour that has been around for many years by now. This is thus not really a viable option to explore to fix the inconsistency. Instead, we change the behaviour of how pseudo-opts read via standard input influence the flags such that the effect is fully localized. With this change, when reading `--not` via standard input, it will: - _Not_ influence subsequent revisions or pseudo-options passed on the command line, which is a change in behaviour. - Influence pseudo-options passed via standard input. - Influence normal revisions passed via standard input, which is a change in behaviour. Thus, all flags read via standard input are fully self-contained to that standard input, only. While this is a breaking change as well, the behaviour has only been recently introduced with Git v2.42.0. Furthermore, the current behaviour can be regarded as a simple bug. With that in mind it feels like the right thing to retroactively change it and make the behaviour sane. Signed-off-by: Patrick Steinhardt <ps@pks.im> Reported-by: Christian Couder <christian.couder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-23The twelfth batchJunio C Hamano1-0/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-23Documentation/git-status: add missing line breaksJosh Soref1-0/+2
Signed-off-by: Josh Soref <jsoref@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-21test-lib: set UBSAN_OPTIONS to match ASanJeff King2-0/+4
For a long time we have used ASAN_OPTIONS to set abort_on_error. This is important because we want to notice detected problems even in programs which are expected to fail. But we never did the same for UBSAN_OPTIONS. This means that our UBSan test suite runs might silently miss some cases. It also causes a more visible effect, which is that t4058 complains about unexpected "fixes" (and this is how I noticed the issue): $ make SANITIZE=undefined CC=gcc && (cd t && ./t4058-*) ... ok 8 - git read-tree does not segfault # TODO known breakage vanished ok 9 - reset --hard does not segfault # TODO known breakage vanished ok 10 - git diff HEAD does not segfault # TODO known breakage vanished The tests themselves aren't that interesting. We have a known bug where these programs segfault, and they do when compiled without sanitizers. With UBSan, when the test runs: test_might_fail git read-tree --reset base it gets: cache-tree.c:935:9: runtime error: member access within misaligned address 0x5a5a5a5a5a5a5a5a for type 'struct cache_entry', which requires 8 byte alignment So that's garbage memory which would _usually_ cause us to segfault, but UBSan catches it and complains first about the alignment. That makes sense, but the weird thing is that UBSan then exits instead of aborting, so our test_might_fail call considers that an acceptable outcome and the test "passes". Curiously, this historically seems to have aborted, because I've run "make test" with UBSan many times (and so did our CI) and we never saw the problem. Even more curiously, I see an abort if I use clang with ASan and UBSan together, like: # this aborts! make SANITIZE=undefined,address CC=clang But not with just UBSan, and not with both when used with gcc: # none of these do make SANITIZE=undefined CC=gcc make SANITIZE=undefined CC=clang make SANITIZE=undefined,address CC=gcc Likewise moving to older versions of gcc (I tried gcc-11 and gcc-12 on my Debian system) doesn't abort. Nor does moving around in Git's history. Neither this test nor the relevant code have been touched in a while, and going back to v2.41.0 produces the same outcome (even though many UBSan CI runs have passed in the meantime). So _something_ changed on my system (and likely will soon on other people's, since this is stock Debian unstable), but I didn't track it further. I don't know why it ever aborted in the past, but we definitely should be explicit here and tell UBSan what we want to happen. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-21am: fix error message in parse_opt_show_current_patch()Oswald Buddenhagen1-1/+2
The argument order was incorrect. This was introduced by 246cac8505 (i18n: turn even more messages into "cannot be used together" ones, 2022-01-05). Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-20completion: loosen and document the requirement around completing aliasJunio C Hamano2-2/+21
Recently we started to tell users to spell ": git foo ;" with space(s) around 'foo' for an alias to be completed similarly to the 'git foo' command. It however is easy to also allow users to spell it in a more natural way with the semicolon attached to 'foo', i.e. ": git foo;". Also, add a comment to note that 'git' is optional and writing ": foo;" would complete the alias just fine. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-20The eleventh batchJunio C Hamano1-0/+27
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-20show doc: redirect user to git log manual instead of git diff-treeHan Young1-1/+1
While git show accepts options that apply to the git diff-tree command, some options do not make sense in the context of git show. The options of git show are handled using the machinery of git log. The git log manual page is a better place to look into than git diff-tree for options that are not in the git show manual page. Signed-off-by: Han Young <hanyang.tony@bytedance.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19range-diff: treat notes like `log`Kristoffer Haugsbakk5-1/+41
Currently, `range-diff` shows the default notes if no notes-related arguments are given. This is also how `log` behaves. But unlike `range-diff`, `log` does *not* show the default notes if `--notes=<custom>` are given. In other words, this: git log --notes=custom is equivalent to this: git log --no-notes --notes=custom While: git range-diff --notes=custom acts like this: git log --notes --notes-custom This can’t be how the user expects `range-diff` to behave given that the man page for `range-diff` under `--[no-]notes[=<ref>]` says: > This flag is passed to the `git log` program (see git-log(1)) that > generates the patches. This behavior also affects `format-patch` since it uses `range-diff` for the cover letter. Unlike `log`, though, `format-patch` is not supposed to show the default notes if no notes-related arguments are given.[1] But this promise is broken when the range-diff happens to have something to say about the changes to the default notes, since that will be shown in the cover letter. Remedy this by introducing `--show-notes-by-default` that `range-diff` can use to tell the `log` subprocess what to do. § Authors • Fix by Johannes • Tests by Kristoffer † 1: See e.g. 66b2ed09c2 (Fix "log" family not to be too agressive about showing notes, 2010-01-20). Co-authored-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Kristoffer Haugsbakk <code@khaugsbakk.name> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19run-command: mark unused parameters in start_bg_wait callbacksJeff King2-2/+4
The start_bg_command() function takes a callback to tell when the background-ed process is "ready". The callback receives the child_process struct as well as an extra void pointer. But curiously, neither of the two users of this interface look at either parameter! This makes some sense. The only non-test user of the API is fsmonitor, which uses fsmonitor_ipc__get_state() to connect to a single global fsmonitor daemon (i.e., the one we just started!). So we could just drop these parameters entirely. But it seems like a pretty reasonable interface for the "wait" callback to have access to the details of the spawned process, and to have room for passing extra data through a void pointer. So let's leave these in place but mark the unused ones so that -Wunused-parameter does not complain. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: mark unused hashmap callback parametersJeff King1-2/+3
Like many hashmap comparison functions, our cookies_cmp() does not look at its extra void data parameter. This should have been annotated in 02c3c59e62 (hashmap: mark unused callback parameters, 2022-08-19), but this new case was added around the same time (plus fsmonitor is not built at all on Linux, so it is easy to miss there). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor/darwin: mark unused parameters in system callbackJeff King1-2/+2
We pass fsevent_callback() to the system FSEventStreamCreate() function as a callback. So we must match the expected function signature, even though we don't care about all of the parameters. Mark the unused ones to satisfy -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: mark unused parameters in stub functionsJeff King3-12/+13
The fsmonitor code has some platform-specific functions for which one or more platforms implement noop or stub functions. We can't get rid of these functions nor change their interface, since the point is to match their equivalents in other platforms. But let's annotate their parameters to quiet the compiler's -Wunused-parameter warning. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor/win32: mark unused parameter in fsm_os__incompatible()Jeff King1-1/+1
We never look at the "ipc" argument we receive. It was added in 8f44976882 (fsmonitor: avoid socket location check if using hook, 2022-10-04) to support the darwin fsmonitor code. The win32 code has to match the same interface, but we should use an annotation to silence -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: mark some maybe-unused parametersJeff King2-2/+3
There's a bit of conditionally-compiled code in fsmonitor, so some function parameters may be unused depending on the build options: - in fsmonitor--daemon.c's try_to_run_foreground_daemon(), we take a detach_console argument, but it's only used on Windows. This seems intentional (and not mistakenly missing other platforms) based on the discussion in c284e27ba7 (fsmonitor--daemon: implement 'start' command, 2022-03-25), which introduced it. - in fsmonitor-setting.c's check_for_incompatible(), we pass the "ipc" flag down to the system-specific fsm_os__incompatible() helper. But we can only do so if our platform has such a helper. In both cases we can mark the argument as MAYBE_UNUSED. That annotates it enough to suppress the compiler's -Wunused-parameter warning, but without making it impossible to use the variable, as a regular UNUSED annotation would. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor/win32: drop unused parametersJeff King1-14/+10
A few helper functions (centered around file-watch events) take extra fsmonitor state parameters that they don't use. These are static helpers local to the win32 implementation, and don't need to conform to any particular interface. We can just drop the extra parameters, which simplifies the code and silences -Wunused-parameter. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-19fsmonitor: prefer repo_git_path() to git_pathdup()Jeff King1-1/+1
The fsmonitor_ipc__get_path() function ignores its repository argument. It should use it when constructing repo paths (though in practice, it is unlikely anything but the_repository is ever passed, so this is cleanup and future proofing, not a bug fix). Note that despite the lack of "dup" in the name, repo_git_path() behaves like git_pathdup() and returns an allocated string. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-18The tenth batchJunio C Hamano1-0/+9
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-18git-send-email.perl: avoid printing undef when validating addressesTaylor Blau1-3/+3
When validating email addresses with `extract_valid_address_or_die()`, we print out a helpful error message when the given input does not contain a valid email address. However, the pre-image of this patch looks something like: my $address = shift; $address = extract_valid_address($address): die sprintf(__("..."), $address) if !$address; which fails when given a bogus email address by trying to use $address (which is undef) in a sprintf() expansion, like so: $ git.compile send-email --to="pi <pi@pi>" /tmp/x/*.patch --force Use of uninitialized value $address in sprintf at /home/ttaylorr/src/git/git-send-email line 1175. error: unable to extract a valid address from: This regression dates back to e431225569 (git-send-email: remove invalid addresses earlier, 2012-11-22), but became more noticeable in a8022c5f7b (send-email: expose header information to git-send-email's sendemail-validate hook, 2023-04-19), which validates SMTP headers in the sendemail-validate hook. Avoid trying to format an undef by storing the given and cleaned address separately. After applying this fix, the error contains the invalid email address, and the warning disappears: $ git.compile send-email --to="pi <pi@pi>" /tmp/x/*.patch --force error: unable to extract a valid address from: pi <pi@pi> Reported-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-18git-gui - use git-hook, honor core.hooksPathMark Levedahl1-25/+2
git-gui currently runs some hooks directly using its own code written before 2010, long predating git v2.9 that added the core.hooksPath configuration to override the assumed location at $GIT_DIR/hooks. Thus, git-gui looks for and runs hooks including prepare-commit-msg, commit-msg, pre-commit, post-commit, and post-checkout from $GIT_DIR/hooks, regardless of configuration. Commands (e.g., git-merge) that git-gui invokes directly do honor core.hooksPath, meaning the overall behaviour is inconsistent. Furthermore, since v2.36 git exposes its hook execution machinery via `git-hook run`, eliminating the need for others to maintain code duplicating that functionality. Using git-hook will both fix git-gui's current issues on hook configuration and (presumably) reduce the maintenance burden going forward. So, teach git-gui to use git-hook. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-18diff --stat: add config option to limit filename widthDragan Simic9-18/+60
Add new configuration option diff.statNameWidth=<width> that is equivalent to the command-line option --stat-name-width=<width>, but it is ignored by format-patch. This follows the logic established by the already existing configuration option diff.statGraphWidth=<width>. Limiting the widths of names and graphs in the --stat output makes sense for interactive work on wide terminals with many columns, hence the support for these configuration options. They don't affect format-patch because it already adheres to the traditional 80-column standard. Update the documentation and add more tests to cover new configuration option diff.statNameWidth=<width>. While there, perform a few minor code and whitespace cleanups here and there, as spotted. Signed-off-by: Dragan Simic <dsimic@manjaro.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-17git-gui - re-enable use of hook scriptsMark Levedahl1-1/+1
Earlier, commit aae9560a introduced search in $PATH to find executables before running them, avoiding an issue where on Windows a same named file in the current directory can be executed in preference to anything in a directory in $PATH. This search is intended to find an absolute path for a bare executable ( e.g, a function "foo") by finding the first instance of "foo" in a directory given in $PATH, and this search works correctly. The search is explicitly avoided for an executable named with an absolute path (e.g., /bin/sh), and that works as well. Unfortunately, the search is also applied to commands named with a relative path. A hook script (or executable) $HOOK is usually located relative to the project directory as .git/hooks/$HOOK. The search for this will generally fail as that relative path will (probably) not exist on any directory in $PATH. This means that git hooks in general now fail to run. Considerable mayhem could occur should a directory on $PATH be git controlled. If such a directory includes .git/hooks/$HOOK, that repository's $HOOK will be substituted for the one in the current project, with unknown consequences. This lookup failure also occurs in worktrees linked to a remote .git directory using git-new-workdir. However, a worktree using a .git file pointing to a separate git directory apparently avoids this: in that case the hook command is resolved to an absolute path before being passed down to the code introduced in aae9560a. Fix this by replacing the test for an "absolute" pathname to a check for a command name having more than one pathname component. This limits the search and absolute pathname resolution to bare commands. The new test uses tcl's "file split" command. Experiments on Linux and Windows, using tclsh, show that command names with relative and absolute paths always give at least two components, while a bare command gives only one. Linux: puts [file split {foo}] ==> foo Linux: puts [file split {/foo}] ==> / foo Linux: puts [file split {.git/foo}] ==> .git foo Windows: puts [file split {foo}] ==> foo Windows: puts [file split {c:\foo}] ==> c:/ foo Windows: puts [file split {.git\foo}] ==> .git foo The above results show the new test limits search and replacement to bare commands on both Linux and Windows. Signed-off-by: Mark Levedahl <mlevedahl@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-17merge-ort: lowercase a few error messagesJeff King3-5/+5
As noted in CodingGuidelines, error messages should not be capitalized. Fix up a few of these that were copied verbatim from merge-recursive to match our modern style. We'll likewise fix up the matching ones from merge-recursive. We care a bit less there, since the hope is that it will eventually go away. But besides being the right thing to do in the meantime, it is necessary for t6406 to pass both with and without GIT_TEST_MERGE_ALGORITHM set (one of our CI jobs sets it to "recursive", which will use the merge-recursive.c code). An alternative would be to use "grep -i" in the test to check the message, but it's nice for the test suite to be be more exact (we'd notice if the capitalization fix regressed). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-16git-clean doc: fix "without do cleaning" typoCaleb Hill1-1/+1
"quit without do cleaning" is not grammatical. Signed-off-by: Caleb Hill <chill389cc@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-15git-config: fix misworded --type=path explanationEvan Gates1-1/+1
When `--type=<type>` was added as a prefered alias for `--<type>` by fb0dc3bac1 (builtin/config.c: support `--type=<type>` as preferred alias for `--<type>`), the explanation for the path type was reworded. Whereas the previous explanation said "expand a leading `~`" this was changed to "adding a leading `~`". Change "adding" to "expanding" to correctly explain the canonicalization. Signed-off-by: Evan Gates <evan.gates@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-15http: update curl http/2 info matching for curl 8.3.0Jeff King1-0/+14
To redact header lines in http/2 curl traces, we have to parse past some prefix bytes that curl sticks in the info lines it passes to us. That changed once already, and we adapted in db30130165 (http: handle both "h2" and "h2h3" in curl info lines, 2023-06-17). Now it has changed again, in curl's fbacb14c4 (http2: cleanup trace messages, 2023-08-04), which was released in curl 8.3.0. Running a build of git linked against that version will fail to redact the trace (and as before, t5559 notices and complains). The format here is a little more complicated than the other ones, as it now includes a "stream id". This is not constant but is always numeric, so we can easily parse past it. We'll continue to match the old versions, of course, since we want to work with many different versions of curl. We can't even select one format at compile time, because the behavior depends on the runtime version of curl we use, not the version we build against. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-15http: factor out matching of curl http/2 trace linesJeff King1-6/+17
We have to parse out curl's http/2 trace lines so we can redact their headers. We already match two different types of lines from various vintages of curl. In preparation for adding another (which will be slightly more complex), let's pull the matching into its own function, rather than doing it in the middle of a conditional. While we're doing so, let's expand the comment a bit to describe the two matches. That probably should have been part of db30130165 (http: handle both "h2" and "h2h3" in curl info lines, 2023-06-17), but will become even more important as we add new types. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-14merge-ort: drop unused "opt" parameter from merge_check_renames_reusable()Jeff King1-3/+2
The merge_options parameter has never been used since the function was introduced in 64aceb6d73 (merge-ort: add code to check for whether cached renames can be reused, 2021-05-20). In theory some merge options might impact our decisions here, but that has never been the case so far. Let's drop it to appease -Wunused-parameter; it would be easy to add back later if we need to (there is only one caller). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-09-14merge-ort: drop unused parameters from detect_and_process_renames()Jeff King1-6/+2
This function takes three trees representing the merge base and both sides of the merge, but never looks at any of them. This is due to f78cf97617 (merge-ort: call diffcore_rename() directly, 2021-02-14). Prior to that commit, we passed pairs of trees to diff_tree_oid(). But after that commit, we collect a custom diff_queue for each pair in the merge_options struct, and just run diffcore_rename() on the result. So the function does not need to know about the original trees at all anymore. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>