summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-12-01Merge branch 'ds/test-read-graph'Libravatar Junio C Hamano8-82/+58
Dev support for commit-graph feature. * ds/test-read-graph: test-tool: use 'read-graph' helper
2019-12-01Merge branch 'rs/use-copy-array-in-mingw-shell-command-preparation'Libravatar Junio C Hamano1-1/+1
Code cleanup. * rs/use-copy-array-in-mingw-shell-command-preparation: mingw: use COPY_ARRAY for copying array
2019-12-01Merge branch 'rs/parse-options-dup-null-fix'Libravatar Junio C Hamano1-1/+2
Code cleanup. * rs/parse-options-dup-null-fix: parse-options: avoid arithmetic on pointer that's potentially NULL
2019-12-01Merge branch 'jt/fetch-remove-lazy-fetch-plugging'Libravatar Junio C Hamano6-25/+108
"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 Hamano3-6/+19
Code clean-up. * jk/optim-in-pack-idx-conversion: pack-objects: avoid pointless oe_map_new_pack() calls
2019-12-01Merge branch 'dl/complete-rebase-onto'Libravatar Junio C Hamano1-0/+4
The completion script (in contrib/) learned that the "--onto" option of "git rebase" can take its argument as the value of the option. * dl/complete-rebase-onto: completion: learn to complete `git rebase --onto=`
2019-12-01Merge branch 'tg/stash-refresh-index'Libravatar Junio C Hamano2-5/+9
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 'nn/doc-rebase-merges'Libravatar Junio C Hamano1-2/+2
Doc update. * nn/doc-rebase-merges: doc: improve readability of --rebase-merges in git-rebase
2019-12-01Merge branch 'dd/sequencer-utf8'Libravatar Junio C Hamano7-9/+193
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 'jk/remove-sha1-to-hex'Libravatar Junio C Hamano4-47/+5
Code clean-up. * jk/remove-sha1-to-hex: hex: drop sha1_to_hex() hex: drop sha1_to_hex_r()
2019-12-01Merge branch 'dj/typofix-merge-strat'Libravatar Junio C Hamano1-1/+1
Typofix. * dj/typofix-merge-strat: merge-strategies: fix typo "reflected to" to "reflected in"
2019-12-01Merge branch 'rj/bundle-ui-updates'Libravatar Junio C Hamano4-53/+211
"git bundle" has been taught to use the parse options API. "git bundle verify" learned "--quiet" and "git bundle create" learned options to control the progress output. * rj/bundle-ui-updates: bundle-verify: add --quiet bundle-create: progress output control bundle: framework for options before bundle file
2019-12-01Merge branch 'rs/skip-iprefix'Libravatar Junio C Hamano2-19/+12
Code simplification. * rs/skip-iprefix: convert: use skip_iprefix() in validate_encoding() utf8: use skip_iprefix() in same_utf_encoding()
2019-12-01Merge branch 'ln/userdiff-elixir'Libravatar Junio C Hamano13-0/+78
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 'py/shortlog-list-options-for-log'Libravatar Junio C Hamano2-1/+13
Documentation pages for "git shortlog" now lists commit limiting options explicitly. * py/shortlog-list-options-for-log: git-shortlog.txt: include commit limiting options
2019-12-01Merge branch 'en/doc-typofix'Libravatar Junio C Hamano141-214/+214
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 'en/misc-doc-fixes'Libravatar Junio C Hamano3-5/+5
Misc doc fixes. * en/misc-doc-fixes: name-hash.c: remove duplicate word in comment hashmap: fix documentation misuses of -> versus . git-filter-branch.txt: correct argument name typo
2019-12-01Merge branch 'js/fetch-multi-lockfix'Libravatar Junio C Hamano2-2/+12
Fetching from multiple remotes into the same repository in parallel had a bad interaction with the recent change to (optionally) update the commit-graph after a fetch job finishes, as these parallel fetches compete with each other. Which has been corrected. * js/fetch-multi-lockfix: fetch: avoid locking issues between fetch.jobs/fetch.writeCommitGraph fetch: add the command-line option `--write-commit-graph`
2019-12-01Merge branch 'rs/trace2-dots'Libravatar Junio C Hamano1-15/+2
Code cleanup. * rs/trace2-dots: trace2: add dots directly to strbuf in perf_fmt_prepare()
2019-12-01Merge branch 'kw/fsmonitor-watchman-fix'Libravatar Junio C Hamano2-18/+8
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 'cb/curl-use-xmalloc'Libravatar Junio C Hamano1-10/+8
HTTP transport had possible allocator/deallocator mismatch, which has been corrected. * cb/curl-use-xmalloc: remote-curl: unbreak http.extraHeader with custom allocators
2019-12-01Merge branch 'rt/fetch-message-fix'Libravatar Junio C Hamano1-1/+1
A small message update. * rt/fetch-message-fix: fetch.c: fix typo in a warning message
2019-12-01Merge branch 'es/myfirstcontrib-updates'Libravatar Junio C Hamano1-3/+50
Doc updates. * es/myfirstcontrib-updates: myfirstcontrib: hint to find gitgitgadget allower myfirstcontrib: add dependency installation step myfirstcontrib: add 'psuh' to command-list.txt
2019-12-01Merge branch 'hw/config-doc-in-header'Libravatar Junio C Hamano2-319/+335
Follow recent push to move API docs from Documentation/ to header files and update config.h * hw/config-doc-in-header: config: move documentation to config.h
2019-12-01Merge branch 'dl/doc-diff-no-index-implies-exit-code'Libravatar Junio C Hamano1-1/+1
Doc update. * dl/doc-diff-no-index-implies-exit-code: git-diff.txt: document return code of `--no-index`
2019-12-01Merge branch 'js/vreportf-wo-buffering'Libravatar Junio C Hamano1-4/+16
Messages from die() etc. can be mixed up from multiple processes without even line buffering on Windows, which has been worked around. * js/vreportf-wo-buffering: vreportf(): avoid relying on stdio buffering
2019-12-01Merge branch 'pb/no-recursive-reset-hard-in-worktree-add'Libravatar Junio C Hamano2-1/+25
"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 'pb/help-list-gitsubmodules-among-guides'Libravatar Junio C Hamano2-1/+2
Help update. * pb/help-list-gitsubmodules-among-guides: help: add gitsubmodules to the list of guides
2019-12-01Merge branch 'sg/blame-indent-heuristics-is-now-the-default'Libravatar Junio C Hamano1-8/+0
Message update. * sg/blame-indent-heuristics-is-now-the-default: builtin/blame.c: remove '--indent-heuristic' from usage string
2019-12-01Merge branch 'mr/clone-dir-exists-to-path-exists'Libravatar Junio C Hamano1-4/+4
Code cleanup. * mr/clone-dir-exists-to-path-exists: clone: rename static function `dir_exists()`.
2019-12-01Merge branch 'ma/bisect-doc-sample-update'Libravatar Junio C Hamano1-1/+1
"git merge --no-commit" needs "--no-ff" if you do not want to move HEAD, which has been corrected in the manual page for "git bisect". * ma/bisect-doc-sample-update: Documentation/git-bisect.txt: add --no-ff to merge command
2019-12-01Merge branch 'js/git-path-head-dot-lock-fix'Libravatar Junio C Hamano3-8/+18
"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 Hamano6-326/+659
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 Hamano9-302/+312
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-14stash: make sure we have a valid index before writing itLibravatar Thomas Gummerer2-5/+9
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-13promisor-remote: remove fetch_if_missing=0Libravatar Jonathan Tan2-17/+32
Commit 6462d5eb9a ("fetch: remove fetch_if_missing=0", 2019-11-08) strove to remove the need for fetch_if_missing=0 from the fetching mechanism, so it is plausible to attempt removing fetch_if_missing=0 from the lazy-fetching mechanism in promisor-remote as well. But doing so reveals a bug - when the server does not send an object pointed to by a tag object, an infinite loop occurs: Git attempts to fetch the missing object, which causes a deferencing of all refs (for negotiation), which causes a lazy fetch of that missing object, and so on. This bug is because of unnecessary use of the fetch negotiator during lazy fetching - it is not used after initialization, but it is still initialized (which causes the dereferencing of all refs). Thus, when the negotiator is not used during fetching, refrain from initializing it. Then, remove fetch_if_missing from promisor-remote. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13clone: remove fetch_if_missing=0Libravatar Jonathan Tan2-4/+2
Commit 6462d5eb9a ("fetch: remove fetch_if_missing=0", 2019-11-08) strove to remove the need for fetch_if_missing=0 from the fetching mechanism, so it is plausible to attempt removing fetch_if_missing=0 from clone as well. But doing so reveals a bug - when the server does not send an object directly pointed to by a ref, this should be an error, not a trigger for a lazy fetch. (This case in the fetching mechanism was covered by a test using "git clone", not "git fetch", which is why the aforementioned commit didn't uncover the bug.) The bug can be fixed by suppressing lazy-fetching during the connectivity check. Fix this bug, and remove fetch_if_missing from clone. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13parse-options: avoid arithmetic on pointer that's potentially NULLLibravatar René Scharfe1-1/+2
parse_options_dup() counts the number of elements in the given array without the end marker, allocates enough memory to hold all of them plus an end marker, then copies them and terminates the new array. The counting part is done by advancing a pointer through the array, and the original pointer is reconstructed using pointer subtraction before the copy operation. The function is also prepared to handle a NULL pointer passed to it. None of its callers do that currently, but this feature was used by 46e91b663b ("checkout: split part of it to new command 'restore'", 2019-04-25); it seems worth keeping. It ends up doing arithmetic on that NULL pointer, though, which is undefined in standard C, when it tries to calculate "NULL - 0". Better avoid doing that by remembering the originally given pointer value. There is another issue, though. memcpy(3) does not support NULL pointers, even for empty arrays. Use COPY_ARRAY instead, which does support such empty arrays. Its call is also shorter and safer by inferring the element type automatically. Coccinelle and contrib/coccinelle/array.cocci did not propose to use COPY_ARRAY because of the pointer subtraction and because the source is const -- the semantic patch cautiously only considers pointers and array references of the same type. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13mingw: use COPY_ARRAY for copying arrayLibravatar René Scharfe1-1/+1
Use the macro COPY_ARRAY to copy array elements. The result is shorter and safer, as it infers the element type automatically and does a (very) basic type compatibility check for its first two arguments. Coccinelle and contrib/coccinelle/array.cocci did not generate this conversion due to the offset of 1 at both source and destination and because the source is a const pointer; the semantic patch cautiously handles only pure pointers and array references of the same type. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-13test-tool: use 'read-graph' helperLibravatar Derrick Stolee8-82/+58
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-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-13hex: drop sha1_to_hex()Libravatar Jeff King4-24/+5
There's only a single caller left of sha1_to_hex(), since everybody that has an object name in "unsigned char[]" now uses hash_to_hex() instead. This case is in the sha1dc wrapper, where we print a hex sha1 when we find a collision. This one will always be sha1, regardless of the current hash algorithm, so we can't use hash_to_hex() here. In practice we'd probably not be running sha1 at all if it isn't the current algorithm, but it's possible we might still occasionally need to compute a sha1 in a post-sha256 world. Since sha1_to_hex() is just a wrapper for hash_to_hex_algop(), let's call that ourselves. There's value in getting rid of the sha1-specific wrapper to de-clutter the global namespace, and to make sure nobody uses it (and as with sha1_to_hex_r() in the previous patch, we'll drop the coccinelle transformations, too). The sha1_to_hex() function is mentioned in a comment; we can easily swap that out for oid_to_hex() to give a better example. Also update the comment that was left stale when we added "struct object_id *" as a way to name an object and added functions to convert it to hex. The function is also mentioned in some test vectors in t4100, but that's not runnable code, so there's no point in trying to clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-12completion: learn to complete `git rebase --onto=`Libravatar Denton Liu1-0/+4
In 2b9bd488ae ("completion: teach rebase to use __gitcomp_builtin", 2019-09-12), the completion script learned to complete rebase using __gitcomp_builtin(). However, this resulted in `--onto=` being suggested instead of `--onto `. Before, when there was a space, we'd start a new word and, as a result, fallback to __git_complete_refs() and `--onto` would be completed this way. However, now we match the `--*` case which does not know how to offer completions for refs. Teach _git_rebase() to complete refs in the `--onto=` case so that we fix this regression. Reported-by: Paul Jolly <paul@myitcv.io> 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 King3-6/+19
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-12doc: improve readability of --rebase-merges in git-rebaseLibravatar Naveen Nathan1-2/+2
When --preserve-merges was deprecated in 427c3bd28a a sentence was introduced describing the difference between --rebase-merges and --preserve-merges which is a little unclear and difficult to parse. This patch improves readability while retaining original meaning. Signed-off-by: Naveen Nathan <naveen@lastninja.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11hex: drop sha1_to_hex_r()Libravatar Jeff King3-23/+0
There are no callers left; everybody uses oid_to_hex_r() or hash_to_hex_algop_r(). This used to actually be the underlying implementation for oid_to_hex_r(), but that's no longer the case since 47edb64997 (hex: introduce functions to print arbitrary hashes, 2018-11-14). Let's get rid of it to de-clutter and to make sure nobody uses it. Likewise we can drop the coccinelle rules that mention it, since the compiler will make it quite clear that the code does not work. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-11-11sequencer: reencode commit message for am/rebase --show-current-patchLibravatar Doan Tran Cong Danh3-1/+32
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 Danh3-1/+63
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>