summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-05-07credential: document protocol updatesCarlo Marcelo Arenas Belón1-13/+21
Document protocol changes after CVE-2020-11008, including the removal of references to the override of attributes which is no longer recommended after CVE-2020-5260 and that might be removed in the future. While at it do some improvements for clarity and consistency. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07credential: update gitcredentials documentationCarlo Marcelo Arenas Belón1-8/+18
Clarify the expected effect of all attributes and how the helpers are expected to handle them and the context where they operate. While at it, space the descriptions for clarity, and add a paragraph mentioning the early termination in the list processing of helpers, to complement the one about the special "quit" attribute. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07t/test_lib: avoid naked bash arrays in file_linenoCarlo Marcelo Arenas Belón1-8/+10
662f9cf154 (tests: when run in Bash, annotate test failures with file name/line number, 2020-04-11), introduces a way to report the location (file:lineno) of a failed test case by traversing the bash callstack. The implementation requires bash and uses shell arrays and is therefore protected by a guard but NetBSD sh will still have to parse the function and therefore will result in: ** t0000-basic.sh *** ./test-lib.sh: 681: Syntax error: Bad substitution Enclose the bash specific code inside an eval to avoid parsing errors in the same way than 5826b7b595 (test-lib: check Bash version for '-x' without using shell arrays, 2019-01-03) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07t/t0000-basic: make sure subtests also use TEST_SHELL_PATHCarlo Marcelo Arenas Belón1-5/+2
3f824e91c8 (t/Makefile: introduce TEST_SHELL_PATH, 2017-12-08) allows for setting a shell for running the tests, but the generated subtests weren't updated. Correct that and while at it update it to use write_script. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07ci: allow per-branch config for GitHub ActionsJeff King2-0/+68
Depending on the workflows of individual developers, it can either be convenient or annoying that our GitHub Actions CI jobs are run on every branch. As an example of annoying: if you carry many half-finished work-in-progress branches and rebase them frequently against master, you'd get tons of failure reports that aren't interesting (not to mention the wasted CPU). This commit adds a new job which checks a special branch within the repository for CI config, and then runs a shell script it finds there to decide whether to skip the rest of the tests. The default will continue to run tests for all refs if that branch or script is missing. There have been a few alternatives discussed: One option is to carry information in the commit itself about whether it should be tested, either in the tree itself (changing the workflow YAML file) or in the commit message (a "[skip ci]" flag or similar). But these are frustrating and error-prone to use: - you have to manually apply them to each branch that you want to mark - it's easy for them to leak into other workflows, like emailing patches We could likewise try to get some information from the branch name. But that leads to debates about whether the default should be "off" or "on", and overriding still ends up somewhat awkward. If we default to "on", you have to remember to name your branches appropriately to skip CI. And if "off", you end up having to contort your branch names or duplicate your pushes with an extra refspec. By comparison, this commit's solution lets you specify your config once and forget about it, and all of the data is off in its own ref, where it can be changed by individual forks without touching the main tree. There were a few design decisions that came out of on-list discussion. I'll summarize here: - we could use GitHub's API to retrieve the config ref, rather than a real checkout (and then just operate on it via some javascript). We still have to spin up a VM and contact GitHub over the network from it either way, so it ends up not being much faster. I opted to go with shell to keep things similar to our other tools (and really could implement allow-refs in any language you want). This also makes it easy to test your script locally, and to modify it within the context of a normal git.git tree. - we could keep the well-known refname out of refs/heads/ to avoid cluttering the branch namespace. But that makes it awkward to manipulate. By contrast, you can just "git checkout ci-config" to make changes. - we could assume the ci-config ref has nothing in it except config (i.e., a branch unrelated to the rest of git.git). But dealing with orphan branches is awkward. Instead, we'll do our best to efficiently check out only the ci/config directory using a shallow partial clone, which allows your ci-config branch to be just a normal branch, with your config changes on top. - we could provide a simpler interface, like a static list of ref patterns. But we can't get out of spinning up a whole VM anyway, so we might as well use that feature to make the config as flexible as possible. If we add more config, we should be able to reuse our partial-clone to set more outputs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07auto-gc: pass --quiet down from am, commit, merge and rebaseJunio C Hamano4-8/+4
These commands take the --quiet option for their own operation, but they forget to pass the option down when they invoke "git gc --auto" internally. Teach them to do so using the run_auto_gc() helper we added in the previous step. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-07auto-gc: extract a reusable helper from "git fetch"Junio C Hamano3-8/+20
Back in 1991006c (fetch: convert argv_gc_auto to struct argv_array, 2014-08-16), we taught "git fetch --quiet" to pass the "--quiet" option down to "gc --auto". This issue, however, is not limited to "fetch": $ git grep -e 'gc.*--auto' \*.c finds hits in "am", "commit", "merge", and "rebase" and these commands do not pass "--quiet" down to "gc --auto" when they themselves are told to be quiet. As a preparatory step, let's introduce a helper function run_auto_gc(), that the caller can pass a boolean "quiet", and redo the fix to "git fetch" using the helper. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-06t5500: count objects through stderr, not traceJonathan Tan1-6/+6
In two tests introduced by 4fa3f00abb ("fetch-pack: in protocol v2, in_vain only after ACK", 2020-04-28) and 2f0a093dd6 ("fetch-pack: in protocol v2, reset in_vain upon ACK", 2020-04-28), the count of objects downloaded is checked by grepping for a specific message in the packet trace. However, this is flaky as that specific message may be delivered over 2 or more packet lines. Instead, grep over stderr, just like the "fetch creating new shallow root" test in the same file. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-06gitfaq: fetching and pulling a repositoryShourya Shukla1-0/+8
Add an issue in 'Common Issues' section which addresses the confusion between performing a 'fetch' and a 'pull'. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-06docs: document credential.helper allowed valuesbrian m. carlson1-3/+7
gitcredentials(7) already mentions several possible invocations that one can use as the value for credential.helper. However, many people are not aware that there are other options than a simple credential helper name, so let's place some explanatory text in the documentation for credential.helper as well. We still refer the user to gitcredential(7) for additional explanations and helpful examples. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-06gitfaq: files in .gitignore are trackedShourya Shukla1-0/+10
Add issue in 'Common Issues' section which addresses the problem of Git tracking files/paths mentioned in '.gitignore'. Signed-off-by: Shourya Shukla <shouryashukla.oo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05Doc: reference the "stash list" in autostash docsDenton Liu2-3/+3
In documentation pertaining to autostash behavior, we refer to the "stash reflog". This description is too low-level as the reflog refers to an implementation detail of how the stash works and, for end-users, they do not need to be aware of this at all. Change references of "stash reflog" to "stash list", which should provide more accessible terminology for end-users. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05The seventh batchJunio C Hamano1-0/+18
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05Merge branch 'js/partial-urlmatch'Junio C Hamano3-3/+29
The same as js/partial-urlmatch-2.17, built on more recent codebase to avoid unnecessary merge conflicts. * js/partial-urlmatch: credential: handle `credential.<partial-URL>.<key>` again credential: optionally allow partial URLs in credential_from_url_gently()
2020-05-05Merge branch 'js/partial-urlmatch-2.17'Junio C Hamano2-6/+84
Recent updates broke parsing of "credential.<url>.<key>" where <url> is not a full URL (e.g. [credential "https://"] helper = ...) stopped working, which has been corrected. * js/partial-urlmatch-2.17: credential: handle `credential.<partial-URL>.<key>` again credential: optionally allow partial URLs in credential_from_url_gently() credential: fix grammar
2020-05-05Merge branch 'tb/commit-graph-perm-bits'Junio C Hamano8-19/+100
Some of the files commit-graph subsystem keeps on disk did not correctly honor the core.sharedRepository settings and some were left read-write. * tb/commit-graph-perm-bits: commit-graph.c: make 'commit-graph-chain's read-only commit-graph.c: ensure graph layers respect core.sharedRepository commit-graph.c: write non-split graphs as read-only lockfile.c: introduce 'hold_lock_file_for_update_mode' tempfile.c: introduce 'create_tempfile_mode'
2020-05-05Merge branch 'dl/push-recurse-submodules-fix'Junio C Hamano1-6/+3
Code cleanup. * dl/push-recurse-submodules-fix: push: unset PARSE_OPT_OPTARG for --recurse-submodules
2020-05-05Merge branch 'dl/opt-callback-cleanup'Junio C Hamano31-181/+173
Code cleanup. * dl/opt-callback-cleanup: Use OPT_CALLBACK and OPT_CALLBACK_F
2020-05-05Merge branch 'jk/test-fail-prereqs-fix'Junio C Hamano1-0/+1
Test update. * jk/test-fail-prereqs-fix: t0000: disable GIT_TEST_FAIL_PREREQS in sub-tests
2020-05-05Merge branch 'dd/iso-8601-updates'Junio C Hamano3-16/+62
The approxidate parser learns to parse seconds with fraction. * dd/iso-8601-updates: date.c: allow compact version of ISO-8601 datetime date.c: skip fractional second part of ISO-8601 date.c: validate and set time in a helper function date.c: s/is_date/set_date/
2020-05-05Merge branch 'bc/wildcard-credential'Junio C Hamano4-6/+58
Update the parser used for credential.<URL>.<variable> configuration, to handle <URL>s with '/' in them correctly. * bc/wildcard-credential: credential: fix matching URLs with multiple levels in path
2020-05-05restore: default to HEAD when combining --staged and --worktreeEric Sunshine3-10/+18
By default, files are restored from the index for --worktree, and from HEAD for --staged. When --worktree and --staged are combined, --source must be specified to disambiguate the restore source[1], thus making it cumbersome to restore a file in both the worktree and the index. However, HEAD is also a reasonable default for --worktree when combined with --staged, so make it the default anytime --staged is used (whether combined with --worktree or not). [1]: Due to an oversight, the --source requirement, though documented, is not actually enforced. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Reviewed-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05builtin/receive-pack: avoid generic function name hmac()Carlo Marcelo Arenas Belón1-3/+3
fabec2c5c3 (builtin/receive-pack: switch to use the_hash_algo, 2019-08-18) renames hmac_sha1 to hmac, as it was updated to use the hash function used by git (which won't be sha1 in the future). hmac() is provided by NetBSD >= 8 libc and therefore conflicts as shown by : builtin/receive-pack.c:421:13: error: conflicting types for 'hmac' static void hmac(unsigned char *out, ^~~~ In file included from ./git-compat-util.h:172:0, from ./builtin.h:4, from builtin/receive-pack.c:1: /usr/include/stdlib.h:305:10: note: previous declaration of 'hmac' was here ssize_t hmac(const char *, const void *, size_t, const void *, size_t, void *, ^~~~ Rename it again to hmac_hash to reflect it will use the git's defined hash function and avoid the conflict, while at it update a comment to better describe the HMAC function that was used. Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-05Merge branch 'ar/ui-ready-semicolon'Pratyush Yadav3-6/+6
Fix syntax error popups because of missing semicolons. * ar/ui-ready-semicolon: Subject: git-gui: fix syntax error because of missing semicolon
2020-05-04commit-graph.c: extract 'refs_cb_data'Taylor Blau1-3/+11
In subsequent patches, we are going to update a progress meter when 'add_ref_to_set()' is called, and need a convenient way to pass a 'struct progress *' in from the caller. Introduce 'refs_cb_data' as a catch-all for parameters that 'add_ref_to_set' may need, and wrap the existing single parameter in that struct. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04credential: correct order of parameters for credential_matchCarlo Marcelo Arenas Belón1-2/+2
Since the beginning in 118250728e (credential: apply helper config, 2011-12-10), the declaration for that function used a different order than the implementation. All callers use the same order than the implementation, so update the declaration in credential.h to match. Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04credential: update description for credential_from_url_gentlyCarlo Marcelo Arenas Belón1-2/+2
c44088ecc4 (credential: treat URL without scheme as invalid, 2020-04-18) changes the implementation for this function to return -1 if protocol is missing. Update blurb to match implementation. Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04pack-bitmap: pass object filter to fill-in traversalJeff King2-5/+14
Sometimes a bitmap traversal still has to walk some commits manually, because those commits aren't included in the bitmap packfile (e.g., due to a push or commit since the last full repack). If we're given an object filter, we don't pass it down to this traversal. It's not necessary for correctness because the bitmap code has its own filters to post-process the bitmap result (which it must, to filter out the objects that _are_ mentioned in the bitmapped packfile). And with blob filters, there was no performance reason to pass along those filters, either. The fill-in traversal could omit them from the result, but it wouldn't save us any time to do so, since we'd still have to walk each tree entry to see if it's a blob or not. But now that we support tree filters, there's opportunity for savings. A tree:depth=0 filter means we can avoid accessing trees entirely, since we know we won't them (or any of the subtrees or blobs they point to). The new test in p5310 shows this off (the "partial bitmap" state is one where HEAD~100 and its ancestors are all in a bitmapped pack, but HEAD~100..HEAD are not). Here are the results (run against linux.git): Test HEAD^ HEAD ------------------------------------------------------------------------------------------------- [...] 5310.16: rev-list with tree filter (partial bitmap) 0.19(0.17+0.02) 0.03(0.02+0.01) -84.2% The absolute number of savings isn't _huge_, but keep in mind that we only omitted 100 first-parent links (in the version of linux.git here, that's 894 actual commits). In a more pathological case, we might have a much larger proportion of non-bitmapped commits. I didn't bother creating such a case in the perf script because the setup is expensive, and this is plenty to show the savings as a percentage. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04pack-bitmap.c: support 'tree:0' filteringTaylor Blau3-1/+50
In the previous patch, we made it easy to define other filters that exclude all objects of a certain type. Use that in order to implement bitmap-level filtering for the '--filter=tree:<n>' filter when 'n' is equal to 0. The general case is not helped by bitmaps, since for values of 'n > 0', the object filtering machinery requires a full-blown tree traversal in order to determine the depth of a given tree. Caching this is non-obvious, too, since the same tree object can have a different depth depending on the context (e.g., a tree was moved up in the directory hierarchy between two commits). But, the 'n = 0' case can be helped, and this patch does so. Running p5310.11 in this tree and on master with the kernel, we can see that this case is helped substantially: Test master this tree -------------------------------------------------------------------------------- 5310.11: rev-list count with tree:0 10.68(10.39+0.27) 0.06(0.04+0.01) -99.4% Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04pack-bitmap.c: make object filtering functions genericTaylor Blau1-11/+24
In 4f3bd5606a (pack-bitmap: implement BLOB_NONE filtering, 2020-02-14), filtering support for bitmaps was added for the 'LOFC_BLOB_NONE' filter. In the future, we would like to add support for filters that behave as if they exclude a certain type of object, for e.g., the tree depth filter with depth 0. To prepare for this, make some of the functions used for filtering more generic, such as 'find_tip_blobs' and 'filter_bitmap_blob_none' so that they can work over arbitrary object types. To that end, create 'find_tip_objects' and 'filter_bitmap_exclude_type', and redefine the aforementioned functions in terms of those. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04list-objects-filter: treat NULL filter_options as "disabled"Jeff King1-0/+3
In most callers, we have an actual list_objects_filter_options struct, and if no filtering is desired its "choice" element will be LOFC_DISABLED. However, some code may have only a pointer to such a struct which may be NULL (because _their_ callers didn't care about filtering, either). Rather than forcing them to handle this explicitly like: if (filter_options) traverse_commit_list_filtered(filter_options, revs, show_commit, show_object, show_data, NULL); else traverse_commit_list(revs, show_commit, show_object, show_data); let's just treat a NULL filter_options the same as LOFC_DISABLED. We only need a small change, since that option struct is converted into a real filter only in the "init" function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04commit-graph: avoid memory leaksJonathan Tan1-11/+11
A fuzzer running on the entry point provided by fuzz-commit-graph.c revealed a memory leak when parse_commit_graph() creates a struct bloom_filter_settings and then returns early due to error. Fix that error by always freeing that struct first (if it exists) before returning early due to error. While making that change, I also noticed another possible memory leak - when the BLOOMDATA chunk is provided but not BLOOMINDEXES. Also fix that error. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04ref-filter: apply fallback refname sort only after all user sortsJeff King2-8/+53
Commit 9e468334b4 (ref-filter: fallback on alphabetical comparison, 2015-10-30) taught ref-filter's sort to fallback to comparing refnames. But it did it at the wrong level, overriding the comparison result for a single "--sort" key from the user, rather than after all sort keys have been exhausted. This worked correctly for a single "--sort" option, but not for multiple ones. We'd break any ties in the first key with the refname and never evaluate the second key at all. To make matters even more interesting, we only applied this fallback sometimes! For a field like "taggeremail" which requires a string comparison, we'd truly return the result of strcmp(), even if it was 0. But for numerical "value" fields like "taggerdate", we did apply the fallback. And that's why our multiple-sort test missed this: it uses taggeremail as the main comparison. So let's start by adding a much more rigorous test. We'll have a set of commits expressing every combination of two tagger emails, dates, and refnames. Then we can confirm that our sort is applied with the correct precedence, and we'll be hitting both the string and value comparators. That does show the bug, and the fix is simple: moving the fallback to the outer compare_refs() function, after all ref_sorting keys have been exhausted. Note that in the outer function we don't have an "ignore_case" flag, as it's part of each individual ref_sorting element. It's debatable what such a fallback should do, since we didn't use the user's keys to match. But until now we have been trying to respect that flag, so the least-invasive thing is to try to continue to do so. Since all callers in the current code either set the flag for all keys or for none, we can just pull the flag from the first key. In a hypothetical world where the user really can flip the case-insensitivity of keys separately, we may want to extend the code to distinguish that case from a blanket "--ignore-case". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04ref-filter: apply --ignore-case to all sorting keysJeff King6-3/+51
All of the ref-filter users (for-each-ref, branch, and tag) take an --ignore-case option which makes filtering and sorting case-insensitive. However, this option was applied only to the first element of the ref_sorting list. So: git for-each-ref --ignore-case --sort=refname would do what you expect, but: git for-each-ref --ignore-case --sort=refname --sort=taggername would sort the primary key (taggername) case-insensitively, but sort the refname case-sensitively. We have two options here: - teach callers to set ignore_case on the whole list - replace the ref_sorting list with a struct that contains both the list of sorting keys, as well as options that apply to _all_ keys I went with the first one here, as it gives more flexibility if we later want to let the users set the flag per-key (presumably through some special syntax when defining the key; for now it's all or nothing through --ignore-case). The new test covers this by sorting on both tagger and subject case-insensitively, which should compare "a" and "A" identically, but still sort them before "b" and "B". We'll break ties by sorting on the refname to give ourselves a stable output (this is actually supposed to be done automatically, but there's another bug which will be fixed in the next commit). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04sparse-checkout: stop blocking empty workdirsDerrick Stolee3-41/+13
Remove the error condition when updating the sparse-checkout leaves an empty working directory. This behavior was added in 9e1afb167 (sparse checkout: inhibit empty worktree, 2009-08-20). The comment was added in a7bc906f2 (Add explanation why we do not allow to sparse checkout to empty working tree, 2011-09-22) in response to a "dubious" comment in 84563a624 (unpack-trees.c: cosmetic fix, 2010-12-22). With the recent "cone mode" and "git sparse-checkout init [--cone]" command, it is common to set a reasonable sparse-checkout pattern set of /* !/*/ which matches only files at root. If the repository has no such files, then their "git sparse-checkout init" command will fail. Now that we expect this to be a common pattern, we should not have the commands fail on an empty working directory. If it is a confusing result, then the user can recover with "git sparse-checkout disable" or "git sparse-checkout set". This is especially simple when using cone mode. Reported-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-04CodingGuidelines: drop arithmetic expansion advice to use "$x"Jeff King1-4/+0
The advice to use "$x" rather than "x" in arithmetric expansion was working around a dash bug fixed in 0.5.4. Even Debian oldstable has 0.5.8 these days. And in the meantime, we've added almost two dozen instances of the "x" form which you can find with: git grep '$(([a-z]' and nobody seems to have complained. Let's declare this workaround obsolete and simplify our style guide. Helped-by: Danh Doan <congdanhqx@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-02credential-store: ignore bogus lines from store fileCarlo Marcelo Arenas Belón2-3/+92
With the added checks for invalid URLs in credentials, any locally modified store files which might have empty lines or even comments were reported[1] failing to parse as valid credentials. Instead of doing a hard check for credentials, do a soft one and therefore avoid the reported fatal error. While at it add tests for all known corruptions that are currently ignored to keep track of them and avoid the risk of regressions. [1] https://stackoverflow.com/a/61420852/5005936 Reported-by: Dirk <dirk@ed4u.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Based-on-patch-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-02userdiff: support MarkdownAsh Holland5-0/+29
It's typical to find Markdown documentation alongside source code, and having better context for documentation changes is useful; see also commit 69f9c87d4 (userdiff: add support for Fountain documents, 2015-07-21). The pattern is based on the CommonMark specification 0.29, section 4.2 <https://spec.commonmark.org/> but doesn't match empty headings, as seeing them in a hunk header is unlikely to be useful. Only ATX headings are supported, as detecting setext headings would require printing the line before a pattern matches, or matching a multiline pattern. The word-diff pattern is the same as the pattern for HTML, because many Markdown parsers accept inline HTML. Signed-off-by: Ash Holland <ash@sorrel.sh> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-01The sixth batchJunio C Hamano1-0/+52
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-01Merge branch 'jt/v2-fetch-nego-fix'Junio C Hamano2-12/+86
The upload-pack protocol v2 gave up too early before finding a common ancestor, resulting in a wasteful fetch from a fork of a project. This has been corrected to match the behaviour of v0 protocol. * jt/v2-fetch-nego-fix: fetch-pack: in protocol v2, reset in_vain upon ACK fetch-pack: in protocol v2, in_vain only after ACK fetch-pack: return enum from process_acks()
2020-05-01Merge branch 'js/anonymise-push-url-in-errors'Junio C Hamano1-2/+4
Error and verbose trace messages from "git push" did not redact credential material embedded in URLs. * js/anonymise-push-url-in-errors: push: anonymize URLs in error messages and warnings
2020-05-01Merge branch 'es/bugreport'Junio C Hamano16-131/+458
The "bugreport" tool. * es/bugreport: bugreport: drop extraneous includes bugreport: add compiler info bugreport: add uname info bugreport: gather git version and build info bugreport: add tool to generate debugging info help: move list_config_help to builtin/help
2020-05-01Merge branch 'en/rebase-root-and-fork-point-are-incompatible'Junio C Hamano2-2/+8
Incompatible options "--root" and "--fork-point" of "git rebase" have been marked and documented as being incompatible. * en/rebase-root-and-fork-point-are-incompatible: rebase: display an error if --root and --fork-point are both provided
2020-05-01Merge branch 'ds/build-homebrew-gettext-fix'Junio C Hamano1-2/+11
Recent update to Homebrew used by macOS folks breaks build by moving gettext library and necessary headers. * ds/build-homebrew-gettext-fix: macOS/brew: let the build find gettext headers/libraries/msgfmt
2020-05-01Merge branch 'dd/sparse-fixes'Junio C Hamano8-15/+16
Compilation fix. * dd/sparse-fixes: progress.c: silence cgcc suggestion about internal linkage graph.c: limit linkage of internal variable compat/regex: move stdlib.h up in inclusion chain test-parse-pathspec-file.c: s/0/NULL/ for pointer type
2020-05-01Merge branch 'mt/doc-worktree-ref'Junio C Hamano1-5/+6
Docfix. * mt/doc-worktree-ref: config doc: fix reference to config.worktree info
2020-05-01Merge branch 'eb/gitweb-more-trailers'Junio C Hamano1-1/+1
Gitweb updates. * eb/gitweb-more-trailers: gitweb: Recognize *-to and Closes/Fixes trailers
2020-05-01Merge branch 'ds/multi-pack-index'Junio C Hamano2-5/+1
The multi-pack-index left mmapped file descriptors open when it does not have to. * ds/multi-pack-index: multi-pack-index: close file descriptor after mmap
2020-05-01Merge branch 'ds/blame-on-bloom'Junio C Hamano9-23/+211
"git blame" learns to take advantage of the "changed-paths" Bloom filter stored in the commit-graph file. * ds/blame-on-bloom: test-bloom: check that we have expected arguments test-bloom: fix some whitespace issues blame: drop unused parameter from maybe_changed_path blame: use changed-path Bloom filters tests: write commit-graph with Bloom filters revision: complicated pathspecs disable filters
2020-05-01Merge branch 'gs/commit-graph-path-filter'Junio C Hamano22-11/+1140
Introduce an extension to the commit-graph to make it efficient to check for the paths that were modified at each commit using Bloom filters. * gs/commit-graph-path-filter: bloom: ignore renames when computing changed paths commit-graph: add GIT_TEST_COMMIT_GRAPH_CHANGED_PATHS test flag t4216: add end to end tests for git log with Bloom filters revision.c: add trace2 stats around Bloom filter usage revision.c: use Bloom filters to speed up path based revision walks commit-graph: add --changed-paths option to write subcommand commit-graph: reuse existing Bloom filters during write commit-graph: write Bloom filters to commit graph file commit-graph: examine commits by generation number commit-graph: examine changed-path objects in pack order commit-graph: compute Bloom filters for changed paths diff: halt tree-diff early after max_changes bloom.c: core Bloom filter implementation for changed paths. bloom.c: introduce core Bloom filter constructs bloom.c: add the murmur3 hash implementation commit-graph: define and use MAX_NUM_CHUNKS