summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-12-05Merge branch 'jh/userdiff-python-async'Libravatar Junio C Hamano6-0/+31
The userdiff machinery has been taught that "async def" is another way to begin a "function" in Python. * jh/userdiff-python-async: userdiff: support Python async functions
2019-12-05Merge branch 'dd/rebase-merge-reserves-onto-label'Libravatar Junio C Hamano1-0/+21
The logic to avoid duplicate label names generated by "git rebase --rebase-merges" forgot that the machinery itself uses "onto" as a label name, which must be avoided by auto-generated labels, which has been corrected. * dd/rebase-merge-reserves-onto-label: sequencer: handle rebase-merges for "onto" message
2019-12-05Merge branch 'js/builtin-add-i'Libravatar Junio C Hamano2-0/+29
The beginning of rewriting "git add -i" in C. * js/builtin-add-i: built-in add -i: implement the `help` command built-in add -i: use color in the main loop built-in add -i: support `?` (prompt help) built-in add -i: show unique prefixes of the commands built-in add -i: implement the main loop built-in add -i: color the header in the `status` command built-in add -i: implement the `status` command diff: export diffstat interface Start to implement a built-in version of `git add --interactive`
2019-12-05Merge branch 'js/rebase-r-safer-label'Libravatar Junio C Hamano1-0/+6
A label used in the todo list that are generated by "git rebase --rebase-merges" is used as a part of a refname; the logic to come up with the label has been tightened to avoid names that cannot be used as such. * js/rebase-r-safer-label: rebase -r: let `label` generate safer labels rebase-merges: move labels' whitespace mangling into `label_oid()`
2019-12-01Merge branch 'jk/gitweb-anti-xss'Libravatar Junio C Hamano2-6/+8
Some codepaths in "gitweb" that forgot to escape URLs generated based on end-user input have been corrected. * jk/gitweb-anti-xss: gitweb: escape URLs generated by href() t/gitweb-lib.sh: set $REQUEST_URI t/gitweb-lib.sh: drop confusing quotes t9502: pass along all arguments in xss helper
2019-12-01Merge branch 'ma/t7004'Libravatar Junio C Hamano1-3/+3
Test fix. * ma/t7004: t7004: check existence of correct tag
2019-12-01Merge branch 'sg/skip-skipped-prereq'Libravatar Junio C Hamano1-6/+6
Test update to avoid wasted cycles. * sg/skip-skipped-prereq: test-lib: don't check prereqs of test cases that won't be run anyway
2019-12-01Merge branch 'ds/test-read-graph'Libravatar Junio C Hamano5-2/+57
Dev support for commit-graph feature. * ds/test-read-graph: test-tool: use 'read-graph' helper
2019-12-01Merge branch 'jt/fetch-remove-lazy-fetch-plugging'Libravatar Junio C Hamano1-0/+70
"git fetch" codepath had a big "do not lazily fetch missing objects when I ask if something exists" switch. This has been corrected by marking the "does this thing exist?" calls with "if not please do not lazily fetch it" flag. * jt/fetch-remove-lazy-fetch-plugging: promisor-remote: remove fetch_if_missing=0 clone: remove fetch_if_missing=0 fetch: remove fetch_if_missing=0
2019-12-01Merge branch 'jk/optim-in-pack-idx-conversion'Libravatar Junio C Hamano1-0/+1
Code clean-up. * jk/optim-in-pack-idx-conversion: pack-objects: avoid pointless oe_map_new_pack() calls
2019-12-01Merge branch 'tg/stash-refresh-index'Libravatar Junio C Hamano1-1/+6
Recent update to "git stash pop" made the command empty the index when run with the "--quiet" option, which has been corrected. * tg/stash-refresh-index: stash: make sure we have a valid index before writing it
2019-12-01Merge branch 'dd/sequencer-utf8'Libravatar Junio C Hamano5-2/+130
Handling of commit objects that use non UTF-8 encoding during "rebase -i" has been improved. * dd/sequencer-utf8: sequencer: reencode commit message for am/rebase --show-current-patch sequencer: reencode old merge-commit message sequencer: reencode squashing commit's message sequencer: reencode revert/cherry-pick's todo list sequencer: reencode to utf-8 before arrange rebase's todo list t3900: demonstrate git-rebase problem with multi encoding configure.ac: define ICONV_OMITS_BOM if necessary t0028: eliminate non-standard usage of printf
2019-12-01Merge branch 'ln/userdiff-elixir'Libravatar Junio C Hamano11-0/+64
The patterns to detect function boundary for Elixir language has been added. * ln/userdiff-elixir: userdiff: add Elixir to supported userdiff languages
2019-12-01Merge branch 'en/doc-typofix'Libravatar Junio C Hamano32-62/+62
Docfix. * en/doc-typofix: Fix spelling errors in no-longer-updated-from-upstream modules multimail: fix a few simple spelling errors sha1dc: fix trivial comment spelling error Fix spelling errors in test commands Fix spelling errors in messages shown to users Fix spelling errors in names of tests Fix spelling errors in comments of testcases Fix spelling errors in code comments Fix spelling errors in documentation outside of Documentation/ Documentation: fix a bunch of typos, both old and new
2019-12-01Merge branch 'ns/test-desc-typofix'Libravatar Junio C Hamano1-2/+2
Typofix. * ns/test-desc-typofix: t: fix typo in test descriptions
2019-12-01Merge branch 'en/t6024-style'Libravatar Junio C Hamano1-63/+67
Test updates. * en/t6024-style: t6024: modernize style
2019-12-01Merge branch 'kw/fsmonitor-watchman-fix'Libravatar Junio C Hamano1-9/+4
The watchman integration for fsmonitor was racy, which has been corrected to be more conservative. * kw/fsmonitor-watchman-fix: fsmonitor: fix watchman integration
2019-12-01Merge branch 'pb/no-recursive-reset-hard-in-worktree-add'Libravatar Junio C Hamano1-0/+24
"git worktree add" internally calls "reset --hard" that should not descend into submodules, even when submodule.recurse configuration is set, but it was affected. This has been corrected. * pb/no-recursive-reset-hard-in-worktree-add: worktree: teach "add" to ignore submodule.recurse config
2019-12-01Merge branch 'js/git-path-head-dot-lock-fix'Libravatar Junio C Hamano2-8/+12
"git rev-parse --git-path HEAD.lock" did not give the right path when run in a secondary worktree. * js/git-path-head-dot-lock-fix: git_path(): handle `.lock` files correctly t1400: wrap setup code in test case
2019-12-01Merge branch 'jc/log-graph-simplify'Libravatar Junio C Hamano5-52/+287
The implementation of "git log --graph" got refactored and then its output got simplified. * jc/log-graph-simplify: t4215: use helper function to check output graph: fix coloring of octopus dashes graph: flatten edges that fuse with their right neighbor graph: smooth appearance of collapsing edges on commit lines graph: rename `new_mapping` to `old_mapping` graph: commit and post-merge lines for left-skewed merges graph: tidy up display of left-skewed merges graph: example of graph output that can be simplified graph: extract logic for moving to GRAPH_PRE_COMMIT state graph: remove `mapping_idx` and `graph_update_width()` graph: reduce duplication in `graph_insert_into_new_columns()` graph: reuse `find_new_column_by_commit()` graph: handle line padding in `graph_next_line()` graph: automatically track display width of graph lines
2019-12-01Merge branch 'jk/cleanup-object-parsing-and-fsck'Libravatar Junio C Hamano3-3/+3
Crufty code and logic accumulated over time around the object parsing and low-level object access used in "git fsck" have been cleaned up. * jk/cleanup-object-parsing-and-fsck: (23 commits) fsck: accept an oid instead of a "struct tree" for fsck_tree() fsck: accept an oid instead of a "struct commit" for fsck_commit() fsck: accept an oid instead of a "struct tag" for fsck_tag() fsck: rename vague "oid" local variables fsck: don't require an object struct in verify_headers() fsck: don't require an object struct for fsck_ident() fsck: drop blob struct from fsck_finish() fsck: accept an oid instead of a "struct blob" for fsck_blob() fsck: don't require an object struct for report() fsck: only require an oid for skiplist functions fsck: only provide oid/type in fsck_error callback fsck: don't require object structs for display functions fsck: use oids rather than objects for object_name API fsck_describe_object(): build on our get_object_name() primitive fsck: unify object-name code fsck: require an actual buffer for non-blobs fsck: stop checking tag->tagged fsck: stop checking commit->parent counts fsck: stop checking commit->tree value commit, tag: don't set parsed bit for parse failures ...
2019-11-20userdiff: support Python async functionsLibravatar Josh Holland6-0/+31
Python's async functions (declared with "async def" rather than "def") were not being displayed in hunk headers. This commit teaches git about the async function syntax, and adds tests for the Python userdiff regex. Signed-off-by: Josh Holland <anowlcalledjosh@gmail.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-20sequencer: handle rebase-merges for "onto" messageLibravatar Doan Tran Cong Danh1-0/+21
In order to work correctly, git-rebase --rebase-merges needs to make initial todo list with unique labels. Those unique labels is being handled by employing a hashmap and appending an unique number if any duplicate is found. But, we forget that beside those labels for side branches, we also have a special label `onto' for our so-called new-base. In a special case that any of those labels for side branches named `onto', git will run into trouble. Correct it. Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18rebase -r: let `label` generate safer labelsLibravatar Matthew Rogers1-0/+6
The `label` todo command in interactive rebases creates temporary refs in the `refs/rewritten/` namespace. These refs are stored as loose refs, i.e. as files in `.git/refs/rewritten/`, therefore they have to conform with file name limitations on the current filesystem in addition to the accepted ref format. This poses a problem in particular on NTFS/FAT, where e.g. the colon, double-quote and pipe characters are disallowed as part of a file name. Let's safeguard against this by replacing not only white-space characters by dashes, but all non-alpha-numeric ones. However, we exempt non-ASCII UTF-8 characters from that, as it should be quite possible to reflect branch names such as `↯↯↯` in refs/file names. Signed-off-by: Matthew Rogers <mattr94@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18built-in add -i: implement the `help` commandLibravatar Slavica Đukić1-0/+25
This imitates the code to show the help text from the Perl script `git-add--interactive.perl` in the built-in version. To make sure that it renders exactly like the Perl version of `git add -i`, we also add a test case for that to `t3701-add-interactive.sh`. Signed-off-by: Slavica Đukić <slawica92@hotmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18gitweb: escape URLs generated by href()Libravatar Jeff King1-1/+2
There's a cross-site scripting problem in gitweb, where it will print URLs generated by its href() helper without further quoting. This allows an attacker to point a victim to a specially crafted gitweb URL and inject arbitrary HTML into the resulting page (which the victim sees as coming from gitweb). The base of the URL comes from evaluate_uri(), which pulls the value of $REQUEST_URI via the CGI module. It tries to strip off $PATH_INFO, but fails to do so in some cases (including ones that contain special characters, like "+"). Most of the uses of the URL end up being passed to "$cgi->a(-href = href())", which will get quoted properly by the CGI module. But in a few places, we output them ourselves as part of manually-generated HTML, and whatever was in the original URL will appear unquoted in the output. Given that all of the nearby variables placed into this manual HTML _are_ quoted, it seems like the authors assumed that these URLs would not need quoting. So it's possible that the bug is actually in evaluate_uri(), which should be doing a more careful job of stripping $PATH_INFO. There's some discussion in a comment in that function, as well as the commit message in 81d3fe9f48 (gitweb: fix wrong base URL when non-root DirectoryIndex, 2009-02-15). But I'm not sure I understand it. Regardless, it's a good idea to quote these values at the point of insertion into the HTML output: 1. Even if there is a bug in evaluate_uri(), this would give us belt-and-suspenders protection. 2. evaluate_uri() is only handling the base. Some generated URLs will also mention arbitrary refs or filenames in the repositories, and these should be quoted anyway. 3. It should never _hurt_ to quote (and that's what all of the $cgi->a() calls are doing already). So there may be further work here, but this patch at least prevents the XSS vulnerability, and shouldn't make anything worse. The test here covers the calls in print_feed_meta(), but I manually audited every call to href() to see how its output was used, and quoted appropriately. Most of them are esc_attr(), as they're used in tag attributes, but I used esc_html() when the URLs were printed bare. The distinction is largely academic, as one is implemented as a wrapper for the other. Reported-by: NAKAYAMA DAISUKE <nakyamad@icloud.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18t/gitweb-lib.sh: set $REQUEST_URILibravatar Jeff King1-1/+2
In a real webserver's CGI call, gitweb.cgi would typically see $REQUEST_URI set. This variable does impact how we display our URL in the resulting page, so let's try to make our test as realistic as possible (we can just use the $PATH_INFO our caller passed in, if any). This doesn't change the outcome of any tests, but it will help us add some new tests in a future patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18t/gitweb-lib.sh: drop confusing quotesLibravatar Jeff King1-2/+2
Some variables assignments in gitweb_run() look like this: FOO=""$1"" The extra quotes aren't doing anything. Each set opens and closes an empty string, and $1 is actually outside of any double-quotes (which is OK, because variable assignment does not do whitespace splitting on the expanded value). Let's drop them, as they're simply confusing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-18t9502: pass along all arguments in xss helperLibravatar Jeff King1-2/+2
This function is just a thin wrapper around gitweb_run(), which takes multiple arguments. But we only pass along "$1". Let's pass everything we get, which will let a future patch add an XSS test that affects PATH_INFO (which gitweb_run() takes as $2). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-14t7004: check existence of correct tagLibravatar Martin Ågren1-3/+3
We try to delete the non-existing tag "anothertag", but for the verifications, we check that the tag "myhead" doesn't exist. "myhead" isn't used in this test except for this checking. Comparing to the test two tests earlier, it looks like a copy-paste mistake. Perhaps it's overkill to check that `git tag -d` didn't decide to *create* a tag. But since we're trying to be this careful, let's actually check the correct tag. While we're doing this, let's use a more descriptive tag name instead -- "nonexistingtag" should be obvious. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-14Start to implement a built-in version of `git add --interactive`Libravatar Johannes Schindelin1-0/+4
Unlike previous conversions to C, where we started with a built-in helper, we start this conversion by adding an interception in the `run_add_interactive()` function when the new opt-in `add.interactive.useBuiltin` config knob is turned on (or the corresponding environment variable `GIT_TEST_ADD_I_USE_BUILTIN`), and calling the new internal API function `run_add_i()` that is implemented directly in libgit.a. At this point, the built-in version of `git add -i` only states that it cannot do anything yet. In subsequent patches/patch series, the `run_add_i()` function will gain more and more functionality, until it is feature complete. The whole arc of the conversion can be found in the PRs #170-175 at https://github.com/gitgitgadget/git. The "--helper approach" can unfortunately not be used here: on Windows we face the very specific problem that a `system()` call in Perl seems to close `stdin` in the parent process when the spawned process consumes even one character from `stdin`. Which prevents us from implementing the main loop in C and still trying to hand off to the Perl script. The very real downside of the approach we have to take here is that the test suite won't pass with `GIT_TEST_ADD_I_USE_BUILTIN=true` until the conversion is complete (the `--helper` approach would have let it pass, even at each of the incremental conversion steps). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-14stash: make sure we have a valid index before writing itLibravatar Thomas Gummerer1-1/+6
In 'do_apply_stash()' we refresh the index in the end. Since 34933d0eff ("stash: make sure to write refreshed cache", 2019-09-11), we also write that refreshed index when --quiet is given to 'git stash apply'. However if '--index' is not given to 'git stash apply', we also discard the index in the else clause just before. We need to do so because we use an external 'git update-index --add --stdin', which leads to an out of date in-core index. Later we call 'refresh_and_write_cache', which now leads to writing the discarded index, which means we essentially write an empty index file. This is obviously not correct, or the behaviour the user wanted. We should not modify the users index without being asked to do so. Make sure to re-read the index after discarding the current in-core index, to avoid dealing with outdated information. Instead we could also drop the 'discard_cache()' + 'read_cache()', however that would make it easy to fall into the same trap as 34933d0eff did, so it's better to avoid that. We can also drop the 'refresh_and_write_cache' completely in the quiet case. Previously in legacy stash we relied on 'git status' to refresh the index after calling 'git read-tree' when '--index' was passed to 'git apply'. However the 'reset_tree()' call that replaced 'git read-tree' always passes options that are equivalent to '-m', making the refresh of the index unnecessary. Reported-by: Grzegorz Rajchman <rayman17@gmail.com> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13test-tool: use 'read-graph' helperLibravatar Derrick Stolee5-2/+57
The 'git commit-graph read' subcommand is used in test scripts to check that the commit-graph contents match the expected data. Mostly, this helps check the header information and the list of chunks. Users do not need this information, so move the functionality to a test helper. Reported-by: Bryan Turner <bturner@atlassian.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13test-lib: don't check prereqs of test cases that won't be run anywayLibravatar SZEDER Gábor1-6/+6
With './t1234-foo.sh -r 5,6' we can run only specific test cases in a test script, but our test framwork still evaluates all lazy prereqs that the excluded test cases might depend on. This is unnecessary and produces verbose and trace output that can be distracting. This has been an issue ever since the '-r|--run=' options were introduced in 0445e6f0a1 (test-lib: '--run' to run only specific tests, 2014-04-30), because that commit added the check of the list of test cases specified with '-r' after evaluating the prereqs. Avoid this unnecessary prereq evaluation by checking the list of test cases specified with '-r' before looking at the prereqs. Note that GIT_SKIP_TESTS has always been checked before the prereqs, so prereqs necessary for tests skipped that way were not evaluated. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13t4215: use helper function to check outputLibravatar Denton Liu1-111/+97
When git commands are placed in the upstream of a pipe, their return codes are lost. In this particular case, it is especially bad since we are testing the intricacies of `git log --graph` behavior and if we hit an unexpected failure or segfault, we want to know this. Extract the common output checking logic into check_graph() where we redirect the output of git commands upstream of pipe into a file and have sed read from that file so that git failures are detected. This patch is best viewed with `--color-moved`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12pack-objects: avoid pointless oe_map_new_pack() callsLibravatar Jeff King1-0/+1
This patch fixes an extreme slowdown in pack-objects when you have more than 1023 packs. See below for numbers. Since 43fa44fa3b (pack-objects: move in_pack out of struct object_entry, 2018-04-14), we use a complicated system to save some per-object memory. Each object_entry structs gets a 10-bit field to store the index of the pack it's in. We map those indices into pointers using packing_data->in_pack_by_idx, which we initialize at the start of the program. If we have 2^10 or more packs, then we instead create an array of pack pointers, one per object. This is packing_data->in_pack. So far so good. But there's one other tricky case: if a new pack arrives after we've initialized in_pack_by_idx, it won't have an index yet. We solve that by calling oe_map_new_pack(), which just switches on the fly to the less-optimal in_pack mechanism, allocating the array and back-filling it for already-seen objects. But that logic kicks in even when we've switched to it already (whether because we really did see a new pack, or because we had too many packs in the first place). The result doesn't produce a wrong outcome, but it's very slow. What happens is this: - imagine you have a repo with 500k objects and 2000 packs that you want to repack. - before looking at any objects, we call prepare_in_pack_by_idx(). It starts allocating an index for each pack. On the 1024th pack, it sees there are too many, so it bails, leaving in_pack_by_idx as NULL. - while actually adding objects to the packing list, we call oe_set_in_pack(), which checks whether the pack already has an index. If it's one of the packs after the first 1023, then it doesn't have one, and we'll call oe_map_new_pack(). But there's no useful work for that function to do. We're already using in_pack, so it just uselessly walks over the complete list of objects, trying to backfill in_pack. And we end up doing this for almost 1000 packs (each of which may be triggered by more than one object). And each time it triggers, we may iterate over up to 500k objects. So in the absolute worst case, this is quadratic in the number of objects. The solution is simple: we don't need to bother checking whether the pack has an index if we've already converted to using in_pack, since by definition we're not going to use it. So we can just push the "does the pack have a valid index" check down into that half of the conditional, where we know we're going to use it. The current test in p5303 sadly doesn't notice this problem, since it maxes out at 1000 packs. If we add a new test to it at 2000 packs, it does show the improvement: Test HEAD^ HEAD ---------------------------------------------------------------------- 5303.12: repack (2000) 26.72(39.68+0.67) 15.70(28.70+0.66) -41.2% However, these many-pack test cases are rather expensive to run, so adding larger and larger numbers isn't appealing. Instead, we can show it off more easily by using GIT_TEST_FULL_IN_PACK_ARRAY, which forces us into the absolute worst case: no pack has an index, so we'll trigger oe_map_new_pack() pointlessly for every single object, making it truly quadratic. Here are the numbers (on git.git) with the included change to p5303: Test HEAD^ HEAD ---------------------------------------------------------------------- 5303.3: rev-list (1) 2.05(1.98+0.06) 2.06(1.99+0.06) +0.5% 5303.4: repack (1) 33.45(33.46+0.19) 2.75(2.73+0.22) -91.8% 5303.6: rev-list (50) 2.07(2.01+0.06) 2.06(2.01+0.05) -0.5% 5303.7: repack (50) 34.21(35.18+0.16) 3.49(4.50+0.12) -89.8% 5303.9: rev-list (1000) 2.87(2.78+0.08) 2.88(2.80+0.07) +0.3% 5303.10: repack (1000) 41.26(51.30+0.47) 10.75(20.75+0.44) -73.9% Again, those improvements aren't realistic for the 1-pack case (because in the real world, the full-array solution doesn't kick in), but it's more useful to be testing the more-complicated code path. While we're looking at this issue, we'll tweak one more thing: in oe_map_new_pack(), we call REALLOC_ARRAY(pack->in_pack). But we'd never expect to get here unless we're back-filling it for the first time, in which case it would be NULL. So let's switch that to ALLOC_ARRAY() for clarity, and add a BUG() to document the expectation. Unfortunately this code isn't well-covered in the test suite because it's inherently racy (it only kicks in if somebody else adds a new pack while we're in the middle of repacking). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11sequencer: reencode commit message for am/rebase --show-current-patchLibravatar Doan Tran Cong Danh2-0/+30
The message file will be used as commit message for the git-{am,rebase} --continue. Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11sequencer: reencode old merge-commit messageLibravatar Doan Tran Cong Danh2-0/+61
During rebasing, old merge's message (encoded in old encoding) will be used as message for new merge commit (created by rebase). In case of the value of i18n.commitencoding has been changed after the old merge time. We will receive an unusable message for this new merge. Correct it. This change also notice a breakage with git-rebase label system. Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11sequencer: reencode squashing commit's messageLibravatar Doan Tran Cong Danh1-1/+9
On fixup/squash-ing rebase, git will create new commit in i18n.commitencoding, reencode the commit message to that said encode. Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11sequencer: reencode to utf-8 before arrange rebase's todo listLibravatar Doan Tran Cong Danh1-1/+1
On musl libc, ISO-2022-JP encoder is too eager to switch back to 1 byte encoding, musl's iconv always switch back after every combining character. Comparing glibc and musl's output for this command $ sed q t/t3900/ISO-2022-JP.txt| iconv -f ISO-2022-JP -t utf-8 | iconv -f utf-8 -t ISO-2022-JP | xxd glibc: 00000000: 1b24 4224 4f24 6c24 5224 5b24 551b 2842 .$B$O$l$R$[$U.(B 00000010: 0a . musl: 00000000: 1b24 4224 4f1b 2842 1b24 4224 6c1b 2842 .$B$O.(B.$B$l.(B 00000010: 1b24 4224 521b 2842 1b24 4224 5b1b 2842 .$B$R.(B.$B$[.(B 00000020: 1b24 4224 551b 2842 0a .$B$U.(B. Although musl iconv's output isn't optimal, it's still correct. From commit 7d509878b8, ("pretty.c: format string with truncate respects logOutputEncoding", 2014-05-21), we're encoding the message to utf-8 first, then format it and convert the message to the actual output encoding on git commit --squash. Thus, t3900::test_commit_autosquash_flags is failing on musl libc. Reencode to utf-8 before arranging rebase's todo list. By doing this, we also remove a breakage noticed by a test added in the previous commit. Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11t3900: demonstrate git-rebase problem with multi encodingLibravatar Doan Tran Cong Danh1-0/+29
We're using fixup!/squash! <subject> to mark if current commit will be used to be fixed up or squashed to a previous commit. However, if we're changing i18n.commitencoding after making the original commit but before making the fixing up, we couldn't find the original commit to do the fixup/squash. Add a test to demonstrate that problem. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Doan Tran Cong Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-10Merge branch 'bc/hash-independent-tests-part-6'Libravatar Junio C Hamano14-155/+259
Test updates to prepare for SHA-2 transition continues. * bc/hash-independent-tests-part-6: t4048: abstract away SHA-1-specific constants t4045: make hash-size independent t4044: update test to work with SHA-256 t4039: abstract away SHA-1-specific constants t4038: abstract away SHA-1 specific constants t4034: abstract away SHA-1-specific constants t4027: make hash-size independent t4015: abstract away SHA-1-specific constants t4011: abstract away SHA-1-specific constants t4010: abstract away SHA-1-specific constants t3429: remove SHA1 annotation t1305: avoid comparing extensions rev-parse: add a --show-object-format option t/oid-info: add empty tree and empty blob values t/oid-info: allow looking up hash algorithm name
2019-11-10Merge branch 'js/update-index-ignore-removal-for-skip-worktree'Libravatar Junio C Hamano2-0/+26
"git stash save" in a working tree that is sparsely checked out mistakenly removed paths that are outside the area of interest. * js/update-index-ignore-removal-for-skip-worktree: stash: handle staged changes in skip-worktree files correctly update-index: optionally leave skip-worktree entries alone
2019-11-10Merge branch 'pb/pretty-email-without-domain-part'Libravatar Junio C Hamano3-61/+97
The custom format for "git log --format=<format>" learned the l/L placeholder that is similar to e/E that fills in the e-mail address, but only the local part on the left side of '@'. * pb/pretty-email-without-domain-part: pretty: add "%aL" etc. to show local-part of email addresses t4203: use test-lib.sh definitions t6006: use test-lib.sh definitions
2019-11-10Merge branch 'dl/apply-3way-diff3'Libravatar Junio C Hamano1-26/+29
"git apply --3way" learned to honor merge.conflictStyle configuration variable, like merges would. * dl/apply-3way-diff3: apply: respect merge.conflictStyle in --3way t4108: demonstrate bug in apply t4108: use `test_config` instead of `git config` t4108: remove git command upstream of pipe t4108: replace create_file with test_write_lines
2019-11-10Merge branch 'sg/dir-trie-fixes'Libravatar Junio C Hamano1-0/+2
Code clean-up and a bugfix in the logic used to tell worktree local and repository global refs apart. * sg/dir-trie-fixes: path.c: don't call the match function without value in trie_find() path.c: clarify two field names in 'struct common_dir' path.c: mark 'logs/HEAD' in 'common_list' as file path.c: clarify trie_find()'s in-code comment Documentation: mention more worktree-specific exceptions
2019-11-10Merge branch 'wb/midx-progress'Libravatar Junio C Hamano1-0/+69
The code to generate multi-pack index learned to show (or not to show) progress indicators. * wb/midx-progress: multi-pack-index: add [--[no-]progress] option. midx: honor the MIDX_PROGRESS flag in midx_repack midx: honor the MIDX_PROGRESS flag in verify_midx_file midx: add progress to expire_midx_packs midx: add progress to write_midx_file midx: add MIDX_PROGRESS flag
2019-11-10Merge branch 'en/merge-recursive-directory-rename-fixes'Libravatar Junio C Hamano3-313/+501
When all files from some subdirectory were renamed to the root directory, the directory rename heuristics would fail to detect that as a rename/merge of the subdirectory to the root directory, which has been corrected. * en/merge-recursive-directory-rename-fixes: t604[236]: do not run setup in separate tests merge-recursive: fix merging a subdirectory into the root directory merge-recursive: clean up get_renamed_dir_portion()
2019-11-10Merge branch 'dd/notes-copy-default-dst-to-head'Libravatar Junio C Hamano1-4/+42
"git notes copy $original" ought to copy the notes attached to the original object to HEAD, but a mistaken tightening to command line parameter validation made earlier disabled that feature by mistake. * dd/notes-copy-default-dst-to-head: notes: fix minimum number of parameters to "copy" subcommand t3301: test diagnose messages for too few/many paramters
2019-11-10Merge branch 'pw/post-commit-from-sequencer'Libravatar Junio C Hamano2-228/+396
"rebase -i" ceased to run post-commit hook by mistake in an earlier update, which has been corrected. * pw/post-commit-from-sequencer: sequencer: run post-commit hook move run_commit_hook() to libgit and use it there sequencer.h fix placement of #endif t3404: remove uneeded calls to set_fake_editor t3404: set $EDITOR in subshell t3404: remove unnecessary subshell