summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-08-10Fifth batchLibravatar Junio C Hamano1-0/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-10Merge branch 'pb/guide-docs'Libravatar Junio C Hamano9-22/+34
Update "git help guides" documentation organization. * pb/guide-docs: git.txt: add list of guides Documentation: don't hardcode command categories twice help: drop usage of 'common' and 'useful' for guides command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers'
2020-08-10Merge branch 'so/rev-parser-errormessage-fix'Libravatar Junio C Hamano1-1/+1
Error message fix. * so/rev-parser-errormessage-fix: revision: fix die() message for "--unpacked="
2020-08-10Merge branch 'en/eol-attrs-gotchas'Libravatar Junio C Hamano4-36/+15
All "mergy" operations that internally use the merge-recursive machinery should honor the merge.renormalize configuration, but many of them didn't. * en/eol-attrs-gotchas: checkout: support renormalization with checkout -m <paths> merge: make merge.renormalize work for all uses of merge machinery t6038: remove problematic test t6038: make tests fail for the right reason
2020-08-10Merge branch 'jk/compiler-fixes-and-workarounds'Libravatar Junio C Hamano2-6/+4
Small fixes and workarounds. * jk/compiler-fixes-and-workarounds: revision: avoid leak when preparing bloom filter for "/" revision: avoid out-of-bounds read/write on empty pathspec config: work around gcc-10 -Wstringop-overflow warning
2020-08-10Merge branch 'ny/notes-doc-sample-update'Libravatar Junio C Hamano1-1/+1
Doc updates. * ny/notes-doc-sample-update: docs: improve the example that illustrates git-notes path names
2020-08-10Merge branch 'es/adjust-subtree-test-for-merge-msg-update'Libravatar Junio C Hamano1-4/+2
Adjust tests in contrib/ to the recent change to fmt-merge-msg. * es/adjust-subtree-test-for-merge-msg-update: Revert "contrib: subtree: adjust test to change in fmt-merge-msg"
2020-08-10Merge branch 'rs/bisect-oid-to-hex-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * rs/bisect-oid-to-hex-fix: bisect: use oid_to_hex_r() instead of memcpy()+oid_to_hex()
2020-08-10Merge branch 'en/merge-recursive-comment-fixes'Libravatar Junio C Hamano2-9/+9
Comment fix. * en/merge-recursive-comment-fixes: merge-recursive: fix unclear and outright wrong comments
2020-08-10Merge branch 'ma/t1450-quotefix'Libravatar Junio C Hamano1-1/+1
Test fix. * ma/t1450-quotefix: t1450: fix quoting of NUL byte when corrupting pack
2020-08-10Merge branch 'es/worktree-cleanup'Libravatar Junio C Hamano1-15/+3
Code cleanup around "worktree" API implementation. * es/worktree-cleanup: worktree: retire special-case normalization of main worktree path worktree: drop bogus and unnecessary path munging worktree: drop unused code from get_linked_worktree() worktree: drop pointless strbuf_release()
2020-08-10Merge branch 'jk/strvec'Libravatar Junio C Hamano105-1620/+1619
The argv_array API is useful for not just managing argv but any "vector" (NULL-terminated array) of strings, and has seen adoption to a certain degree. It has been renamed to "strvec" to reduce the barrier to adoption. * jk/strvec: strvec: rename struct fields strvec: drop argv_array compatibility layer strvec: update documention to avoid argv_array strvec: fix indentation in renamed calls strvec: convert remaining callers away from argv_array name strvec: convert more callers away from argv_array name strvec: convert builtin/ callers away from argv_array name quote: rename sq_dequote_to_argv_array to mention strvec strvec: rename files from argv-array to strvec argv-array: rename to strvec argv-array: use size_t for count and alloc
2020-08-04git.txt: add list of guidesLibravatar Philippe Blain3-1/+14
Not all man5/man7 guides are mentioned in the 'git(1)' documentation, which makes the missing ones somewhat hard to find. Add a list of the guides to git(1) by leveraging the existing `Documentation/cmd-list.perl` script to generate a file `cmds-guide.txt` which gets included in git.txt. Also, do not hard-code the manual section '1'. Instead, use a regex so that the manual section is discovered from the first line of each `git*.txt` file. This addition was hinted at in 1b81d8cb19 (help: use command-list.txt for the source of guides, 2018-05-20). Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04Documentation: don't hardcode command categories twiceLibravatar Junio C Hamano2-13/+9
Instead of hard-coding the list of command categories in both `Documentation/Makefile` and `Documentation/cmd-list.perl`, make the Makefile the authoritative source and tweak `cmd-list.perl` so that it receives the list of command categories as argument. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04help: drop usage of 'common' and 'useful' for guidesLibravatar Philippe Blain4-7/+7
Since 1b81d8cb19 (help: use command-list.txt for the source of guides, 2018-05-20), all man5/man7 guides listed in command-list.txt appear in the output of 'git help -g'. However, 'git help -g' still prefixes this list with "The common Git guides are:", which makes one wonder if there are others! In the same spirit, the man page for 'git help' describes the '--guides' option as listing 'useful' guides, which is not false per se but can also be taken to mean that there are other guides that exist but are not useful. Instead of 'common' and 'useful', use 'Git concept guides' in both places. To keep the code in line with this change, rename help.c::list_common_guides_help to list_guides_help. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04command-list.txt: add missing 'gitcredentials' and 'gitremote-helpers'Libravatar Philippe Blain3-1/+4
The guides 'gitcredentials' and 'gitremote-helpers' do not currently appear in command-list.txt. 'gitcredentials' was forgotten back when guides were added to command-list.txt in 1b81d8cb19 (help: use command-list.txt for the source of guides, 2018-05-20). 'gitremote-helpers' was moved to section 7 in 439cc74632 (docs: move gitremote-helpers into section 7, 2019-03-25), but command-list.txt was not updated at the time. Add these two guides to the list of guides in 'command-list.txt', so that they appear in the output of 'git help --guides', and capitalize the first word of the description of 'gitcredentials', as was done in 1b81d8c (help: use command-list.txt for the source of guides, 2018-05-20) for the other guides. While at it, add a comment in Documentation/Makefile to remind developers to update command-list.txt if they add a new guide. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04revision: fix die() message for "--unpacked="Libravatar Sergey Organov1-1/+1
Get rid of the trailing dot and mark for translation. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04Fourth batchLibravatar Junio C Hamano1-1/+15
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04Merge branch 'jt/pretend-object-never-come-from-elsewhere'Libravatar Junio C Hamano2-1/+13
The pretend-object mechanism checks if the given object already exists in the object store before deciding to keep the data in-core, but the check would have triggered lazy fetching of such an object from a promissor remote. * jt/pretend-object-never-come-from-elsewhere: sha1-file: make pretend_object_file() not prefetch
2020-08-04Merge branch 'jt/pack-objects-prefetch-in-batch'Libravatar Junio C Hamano2-4/+72
While packing many objects in a repository with a promissor remote, lazily fetching missing objects from the promissor remote one by one may be inefficient---the code now attempts to fetch all the missing objects in batch (obviously this won't work for a lazy clone that lazily fetches tree objects as you cannot even enumerate what blobs are missing until you learn which trees are missing). * jt/pack-objects-prefetch-in-batch: pack-objects: prefetch objects to be packed pack-objects: refactor to oid_object_info_extended
2020-08-04Merge branch 'mp/complete-show-color-moved'Libravatar Junio C Hamano1-0/+8
Command line completion (in contrib/) update. * mp/complete-show-color-moved: completion: add show --color-moved[-ws]
2020-08-04revision: avoid leak when preparing bloom filter for "/"Libravatar Jeff King1-0/+1
If we're given an empty pathspec, we refuse to set up bloom filters, as described in f3c2a36810 (revision: empty pathspecs should not use Bloom filters, 2020-07-01). But before the empty string check, we drop any trailing slash by allocating a new string without it. So a pathspec consisting only of "/" will allocate that string, but then still cause us to bail, leaking the new string. Let's make sure to free it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04revision: avoid out-of-bounds read/write on empty pathspecLibravatar Jeff King1-5/+2
Running t4216 with ASan results in it complaining of an out-of-bounds read in prepare_to_use_bloom_filter(). The issue is this code to strip a trailing slash: last_index = pi->len - 1; if (pi->match[last_index] == '/') { because we have no guarantee that pi->len isn't zero. This can happen if the pathspec is ".", as we translate that to an empty string. And if that read of random memory does trigger the conditional, we'd then do an out-of-bounds write: path_alloc = xstrdup(pi->match); path_alloc[last_index] = '\0'; Let's make sure to check the length before subtracting. Note that for an empty pathspec, we'd end up bailing from the function a few lines later, which makes it tempting to just: if (!pi->len) return; early here. But our code here is stripping a trailing slash, and we need to check for emptiness after stripping that slash, too. So we'd have two blocks, which would require repeating some cleanup code. Instead, just skip the trailing-slash for an empty string. Setting last_index at all in the case is awkward since it will have a nonsense value (and it uses an "int", which is a too-small type for a string anyway). So while we're here, let's: - drop last_index entirely; it's only used in two spots right next to each other and writing out "pi->len - 1" in both is actually easier to follow - use xmemdupz() to duplicate the string. This is slightly more efficient, but more importantly makes the intent more clear by allocating the correct-sized substring in the first place. It also eliminates any question of whether path_alloc is as long as pi->match (which it would not be if pi->match has any embedded NULs, though in practice this is probably impossible). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-04config: work around gcc-10 -Wstringop-overflow warningLibravatar Jeff King1-1/+1
Compiling with gcc-10, -O2, and -fsanitize=undefined results in a compiler warning: config.c: In function ‘git_config_copy_or_rename_section_in_file’: config.c:3170:17: error: writing 1 byte into a region of size 0 [-Werror=stringop-overflow=] 3170 | output[0] = '\t'; | ~~~~~~~~~~^~~~~~ config.c:3076:7: note: at offset -1 to object ‘buf’ with size 1024 declared here 3076 | char buf[1024]; | ^~~ This is a false positive. The interesting lines of code are: int i; char *output = buf; ... for (i = 0; buf[i] && isspace(buf[i]); i++) ; /* do nothing */ ... int offset; offset = section_name_match(&buf[i], old_name); if (offset > 0) { ... output += offset + i; if (strlen(output) > 0) { /* * More content means there's * a declaration to put on the * next line; indent with a * tab */ output -= 1; output[0] = '\t'; } } So we do assign output to buf initially. Later we increment it based on "offset" and "i" and then subtract "1" from it. That latter step is what the compiler is complaining about; it could lead to going off the left side of the array if "output == buf" at the moment of the subtraction. For that to be the case, then "offset + i" would have to be 0. But that can't happen: - we know that "offset" is at least 1, since we're in a conditional block that checks that - we know that "i" is not negative, since it started at 0 and only incremented over whitespace So the sum must be at least 1, and therefore it's OK to subtract one from "output". But that's not quite the whole story. Since "i" is an int, it could in theory be possible to overflow to negative (when counting whitespace on a very large string). But we know that's impossible because we're counting the 1024-byte buffer we just fed to fgets(), so it can never be larger than that. Switching the type of "i" to "unsigned" makes the warning go away, so let's do that. Arguably size_t is an even better type (for this and for the other length fields), but switching to it produces a similar but distinct warning: config.c: In function ‘git_config_copy_or_rename_section_in_file’: config.c:3170:13: error: array subscript -1 is outside array bounds of ‘char[1024]’ [-Werror=array-bounds] 3170 | output[0] = '\t'; | ~~~~~~^~~ config.c:3076:7: note: while referencing ‘buf’ 3076 | char buf[1024]; | ^~~ If we were to ever switch off of fgets() to strbuf_getline() or similar, we'd probably need to use size_t to avoid other overflow problems. But for now we know we're safe because of the small fixed size of our buffer. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03Revert "contrib: subtree: adjust test to change in fmt-merge-msg"Libravatar Emily Shaffer1-4/+2
This reverts commit 508fd8e8baf3e18ee40b2cf0b8899188a8506d07. In 6e6029a8 (fmt-merge-msg: allow merge destination to be omitted again) we get back the behavior where merges against 'master', by default, do not include "into 'master'" at the end of the merge message. This test fix is no longer needed. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03docs: improve the example that illustrates git-notes path namesLibravatar Noam Yorav-Raphael1-1/+1
Make it clear that the filename has only the rest of the object ID, not the entirety of it. Signed-off-by: Noam Yorav-Raphael <noamraph@gmail.com> Acked-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03checkout: support renormalization with checkout -m <paths>Libravatar Elijah Newren1-5/+6
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03merge: make merge.renormalize work for all uses of merge machineryLibravatar Elijah Newren4-13/+5
The 'merge' command is not the only one that does merges; other commands like checkout -m or rebase do as well. Unfortunately, the only area of the code that checked for the "merge.renormalize" config setting was in builtin/merge.c, meaning it could only affect merges performed by the "merge" command. Move the handling of this config setting to merge_recursive_config() so that other commands can benefit from it as well. Fixes a few tests in t6038. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03t6038: remove problematic testLibravatar Elijah Newren1-14/+0
t6038.11, 'cherry-pick patch from after text=auto' was a test of undefined behavior. To make matters worse, while there are a couple possible correct answers, this test was coded to only check for an obviously incorrect answer. And the final cherry on top is that the test is marked test_expect_failure, meaning it can't provide much value, other than possibly confusing future folks who come along and try to work on attributes and look at existing tests. Because of all these problems, just remove the test. But for any future code spelunkers, here's my understanding of the two possible correct answers: This test was set up so that on a branch with no .gitattributes file, you cherry-picked a patch from a branch that had a .gitattributes file (containing '* text=auto'). Further, the two branches had a file which differed only in line endings. In this situation, correct behavior is not well defined: should the .gitattributes file affect the merge or not? If the .gitattributes file on the other branch should not affect the merge, then we would have a content conflict with all three stages different (the merge base didn't match either side). If the .gitattributes file from the other branch should affect the merge, then we would expect the line endings to be normalized to LF for the version to be recorded in the repository. This would mean that when doing a three-way content merge on the file that differed in line endings, that the three-way content merge would see that the versions on both sides matched and so the cherry-pick has no conflicts and can succeed. The line endings in the file as recorded in the repository will change from CRLF to LF. The version checked out in the working copy will depend on the platform (since there's no eol attribute defined for the file). Also, as a final side note, this test expected an error message that was built assuming cherry-pick was the old scripted version, because cherry-pick no longer uses the error message that was encoded in this test. So it was wrong for yet another reason. Given that the handling of .gitattributes is not well defined and this test was obviously broken and could do nothing but confuse future readers, just remove it. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-03t6038: make tests fail for the right reasonLibravatar Elijah Newren1-4/+4
t6038 had a pair of tests that were expected to fail, but weren't failing for the expected reason. Both were meant to do a merge that could be done cleanly after renormalization, but were supposed to fail for lack of renormalization. Unfortunately, both tests had staged changes, and checkout -m would abort due to the presence of those staged changes before even attempting a merge. Fix this first issue by utilizing git-restore instead of git-checkout, so that the index is left alone and just the working directory gets the changes we want. However, there is a second issue with these tests. Technically, they just wanted to verify that after renormalization, no conflicts would be present. This could have been checked for by grepping for a lack of conflict markers, but the test instead tried to compare the working directory files to an expected result. Unfortunately, the setting of "text=auto" without setting core.eol to any value meant that the content of the file (in particular, the line endings) would be platform-dependent and the tests could only pass on some platforms. Replace the existing comparison with a call to 'git diff --no-index --ignore-cr-at-eol' to verify that the contents, other than possible carriage returns in the file, match the expected results and in particular that the file has no conflicts from the checkout -m operation. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-02bisect: use oid_to_hex_r() instead of memcpy()+oid_to_hex()Libravatar René Scharfe1-1/+1
Write the hexadecimal object ID directly into the destination buffer using oid_to_hex_r() instead of writing it into a static buffer first using oid_to_hex() and then copying it from there using memcpy(). This is shorter, simpler and a bit more efficient. Reviewed-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-02merge-recursive: fix unclear and outright wrong commentsLibravatar Elijah Newren2-9/+9
Commits 7c0a6c8e47 ("merge-recursive: move some definitions around to clean up the header", 2019-08-17), and b4db8a2b76 ("merge-recursive: remove useless parameter in merge_trees()", 2019-08-17) added some useful documentation to the functions, but had a few places where the new comments were unclear or even misleading. Fix those comments. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-01t1450: fix quoting of NUL byte when corrupting packLibravatar Martin Ågren1-1/+1
We use printf '\0' to generate a NUL byte which we then `dd` into the packfile to ensure that we modify the first byte of the first object, thereby (probabilistically) invalidating the checksum. Except the single quotes we're using are interpreted to match with the ones we enclose the whole test in. So we actually execute printf \0 and end up injecting the ASCII code for "0", 0x30, instead. The comment right above this `printf` invocation says that "at least one of [the type bits] is not zero, so setting the first byte to 0 is sufficient". Substituting "0x30" for "0" in that comment won't do: we'd need to reason about which bits go where and just what the packfile looks like that we're modifying in this test. Let's avoid all of that by actually executing printf "\0" to generate a NUL byte, as intended. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-01Third batchLibravatar Junio C Hamano1-0/+4
A couple of brown-paper-bag fixes, plus the other "The branch 'master' no longer is special" fix. Now we are ready to rewind 'next'.
2020-08-01Merge branch 'cc/pretty-contents-size' into masterLibravatar Junio C Hamano1-2/+2
Brown-paper-bag fix. * cc/pretty-contents-size: t6300: fix issues related to %(contents:size)
2020-08-01Merge branch 'hn/reftable' into masterLibravatar Junio C Hamano2-2/+3
Brown-paper-bag fix. * hn/reftable: refs: move the logic to add \t to reflog to the files backend
2020-08-01Merge branch 'jc/fmt-merge-msg-suppress-destination' into masterLibravatar Junio C Hamano30-94/+159
"git merge" learned to selectively omit " into <branch>" at the end of the title of default merge message with merge.suppressDest configuration. * jc/fmt-merge-msg-suppress-destination: fmt-merge-msg: allow merge destination to be omitted again Revert "fmt-merge-msg: stop treating `master` specially"
2020-07-31worktree: retire special-case normalization of main worktree pathLibravatar Eric Sunshine1-4/+2
In order for "git-worktree list" to present consistent results, get_main_worktree() performs manual normalization on the repository path (returned by get_common_dir()) after passing it through strbuf_add_absolute_path(). In particular, it cleans up the path for three distinct cases when the current working directory is (1) the main worktree, (2) the .git/ subdirectory, or (3) a bare repository. The need for such special-cases is a direct consequence of employing strbuf_add_absolute_path() which, for the sake of efficiency, doesn't bother normalizing the path (such as folding out redundant path components) after making it absolute. Lack of normalization is not typically a problem since redundant path elements make no difference when working with paths at the filesystem level. However, when preparing paths for presentation, possible redundant path components make it difficult to ensure consistency. Eliminate the need for these special cases by instead making the path absolute via strbuf_add_real_path() which normalizes the path for us. Once normalized, the only case we need to handle manually is converting it to the path of the main worktree by stripping the "/.git" suffix. This stripping of the "/.git" suffix is a regular idiom in worktree-related code; for instance, it is employed by get_linked_worktree(), as well. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31worktree: drop bogus and unnecessary path mungingLibravatar Eric Sunshine1-6/+1
The content of .git/worktrees/<id>/gitdir must be a path of the form "/path/to/worktree/.git". Any other content would be indicative of a corrupt "gitdir" file. To determine the path of the worktree itself one merely strips the "/.git" suffix, and this is indeed how the worktree path was determined from inception. However, 5193490442 (worktree: add a function to get worktree details, 2015-10-08) extended the path manipulation in a mysterious way. If it is unable to strip "/.git" from the path, then it instead reports the current working directory as the linked worktree's path: if (!strbuf_strip_suffix(&worktree_path, "/.git")) { strbuf_reset(&worktree_path); strbuf_add_absolute_path(&worktree_path, "."); strbuf_strip_suffix(&worktree_path, "/."); } This logic is clearly bogus; it can never be generally correct behavior. It materialized out of thin air in 5193490442 with neither explanation nor tests to illustrate a case in which it would be desirable. It's possible that this logic was introduced to somehow deal with a corrupt "gitdir" file, so that it returns _some_ sort of meaningful value, but returning the current working directory is not helpful. In fact, it is quite misleading (except in the one specific case when the current directory is the worktree whose "gitdir" entry is corrupt). Moreover, reporting the corrupt value to the user, rather than fibbing about it and hiding it outright, is more helpful since it may aid in diagnosing the problem. Therefore, drop this bogus path munging and restore the logic to the original behavior of merely stripping "/.git". Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31worktree: drop unused code from get_linked_worktree()Libravatar Eric Sunshine1-3/+0
This code has been unused since fa099d2322 (worktree.c: kill parse_ref() in favor of refs_resolve_ref_unsafe(), 2017-04-24), so drop it. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31worktree: drop pointless strbuf_release()Libravatar Eric Sunshine1-2/+0
The content of this strbuf is unconditionally detached several lines before the strbuf_release() and the strbuf is never touched again after that point. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31t6300: fix issues related to %(contents:size)Libravatar Alban Gruin1-2/+2
b6839fda68 (ref-filter: add support for %(contents:size), 2020-07-16) added a new format for ref-filter, and added a function to generate tests for this new feature in t6300. Unfortunately, it tries to run `test_expect_sucess' instead of `test_expect_success', and writes $expect to `expected', but tries to read `expect'. Those two issues were probably unnoticed because the script only printed errors, but did not crash. This fixes these issues. Signed-off-by: Alban Gruin <alban.gruin@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-31refs: move the logic to add \t to reflog to the files backendLibravatar Han-Wen Nienhuys2-2/+3
523fa69c (reflog: cleanse messages in the refs.c layer, 2020-07-10) centralized reflog normalizaton. However, the normalizaton added a leading "\t" to the message. This is an artifact of the reflog storage format in the files backend, so it should be added there. Routines that parse back the reflog (such as grab_nth_branch_switch) expect the "\t" to not be in the message, so without this fix, git with reftable cannot process the "@{-1}" syntax. Signed-off-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30The second batch -- mostly minor typofixesLibravatar Junio C Hamano1-0/+6
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-30Merge branch 'jb/doc-packfile-name' into masterLibravatar Junio C Hamano2-5/+4
Doc update. * jb/doc-packfile-name: pack-write/docs: update regarding pack naming
2020-07-30Merge branch 'sg/ci-git-path-fix-with-pyenv' into masterLibravatar Junio C Hamano1-2/+2
CI fixup---tests of Python scripts didn't use the version of Git that is being tested. * sg/ci-git-path-fix-with-pyenv: ci: use absolute PYTHON_PATH in the Linux jobs
2020-07-30Merge branch 'en/typofixes' into masterLibravatar Junio C Hamano6-6/+6
* en/typofixes: hashmap: fix typo in usage docs Remove doubled words in various comments
2020-07-30Merge branch 'rs/grep-simpler-parse-object-or-die-call' into masterLibravatar Junio C Hamano1-1/+1
* rs/grep-simpler-parse-object-or-die-call: grep: avoid using oid_to_hex() with parse_object_or_die()
2020-07-30Merge branch 'ar/help-guides-doc' into masterLibravatar Junio C Hamano1-2/+2
* ar/help-guides-doc: git-help.txt: fix mentions of option --guides
2020-07-30Merge branch 'sk/typofixes' into masterLibravatar Junio C Hamano4-4/+4
* sk/typofixes: comment: fix spelling mistakes inside comments