summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2019-09-07builtin/rebase.c: Remove pointless messageLibravatar Ben Wijen1-4/+0
When doing 'git rebase --autostash <upstream> <master>' with a dirty worktree a 'HEAD is now at ...' message is emitted, which is pointless as it refers to the old active branch which isn't actually moved. This commit removes the 'HEAD is now at...' message. Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-07builtin/rebase.c: make sure the active branch isn't moved when autostashingLibravatar Ben Wijen1-0/+8
Consider the following scenario: git checkout not-the-master work work work git rebase --autostash upstream master Here 'rebase --autostash <upstream> <branch>' incorrectly moves the active branch (not-the-master) to master (before the rebase). The expected behavior: (58794775:/git-rebase.sh:526) AUTOSTASH=$(git stash create autostash) git reset --hard git checkout master git rebase upstream git stash apply $AUTOSTASH The actual behavior: (6defce2b:/builtin/rebase.c:1062) AUTOSTASH=$(git stash create autostash) git reset --hard master git checkout master git rebase upstream git stash apply $AUTOSTASH This commit reinstates the 'legacy script' behavior as introduced with 58794775: rebase: implement --[no-]autostash and rebase.autostash Signed-off-by: Ben Wijen <ben@wijen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-09Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano2-9/+8
Test fix. * bc/hash-independent-tests-part-4: t0000: reword comments for "local" test t: decrease nesting in test_oid_to_path
2019-08-09Merge branch 'mt/dir-iterator-updates'Libravatar Junio C Hamano1-3/+1
Leakfix. * mt/dir-iterator-updates: test-dir-iterator: use path argument directly dir-iterator: release strbuf after use
2019-08-08Merge branch 'en/disable-dir-rename-in-recursive-merge'Libravatar Junio C Hamano1-0/+111
"merge-recursive" hit a BUG() when building a virtual merge base detected a directory rename. * en/disable-dir-rename-in-recursive-merge: merge-recursive: avoid directory rename detection in recursive case
2019-08-08t0000: reword comments for "local" testLibravatar Jeff King1-8/+6
Commit 01d3a526ad (t0000: check whether the shell supports the "local" keyword, 2017-10-26) added a test to gather data on whether people run the test suite with shells that don't support "local". After almost two years, nobody has complained, and several other uses have cropped up in test-lib-functions.sh. Let's declare it acceptable to use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-08t: decrease nesting in test_oid_to_pathLibravatar Jonathan Nieder1-1/+2
t1410.3 ("corrupt and checks") fails when run using dash versions before 0.5.8, with a cryptic message: mv: cannot stat '.git/objects//e84adb2704cbd49549e52169b4043871e13432': No such file or directory The function generating that path: test_oid_to_path () { echo "${1%${1#??}}/${1#??}" } which is supposed to produce a result like 12/3456789.... But a dash bug[*] causes it to instead expand to /3456789... The stream of symbols that makes up this function is hard for humans to follow, too. The complexity mostly comes from the repeated use of the expression ${1#??} for the basename of the loose object. Use a variable instead --- nowadays, the dialect of shell used by Git permits local variables, so this is cheap. An alternative way to work around [*] is to remove the double-quotes around test_oid_to_path's return value. That makes the expression easier for dash to read, but harder for humans. Let's prefer the rephrasing that's helpful for humans, too. Noticed by building on Ubuntu trusty, which uses dash 0.5.7. [*] Fixed by v0.5.8~13 ("[EXPAND] Propagate EXP_QPAT in subevalvar, 2013-08-23). Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-07test-dir-iterator: use path argument directlyLibravatar René Scharfe1-3/+1
Avoid allocating and leaking a strbuf for holding a verbatim copy of the path argument and pass the latter directly to dir_iterator_begin() instead. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-06merge-recursive: avoid directory rename detection in recursive caseLibravatar Elijah Newren1-0/+111
Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory rename detection default", 2019-04-05), the default handling with directory rename detection was to report a conflict and leave unstaged entries in the index. However, when creating a virtual merge base in the recursive case, we absolutely need a tree, and the only way a tree can be written is if we have no unstaged entries -- otherwise we hit a BUG(). There are a few fixes possible here which at least fix the BUG(), but none of them seem optimal for other reasons; see the comments with the new testcase 13e in t6043 for details (which testcase triggered a BUG() prior to this patch). As such, just opt for a very conservative and simple choice that is still relatively reasonable: have the recursive case treat 'conflict' as 'false' for opt->detect_directory_renames. Reported-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-05commit-graph: fix bug around octopus mergesLibravatar Derrick Stolee1-1/+3
In 1771be90 "commit-graph: merge commit-graph chains" (2019-06-18), the method sort_and_scan_merged_commits() was added to merge the commit lists of two commit-graph files in the incremental format. Unfortunately, there was an off-by-one error in that method around incrementing num_extra_edges, which leads to an incorrect offset for the base graph chunk. When we store an octopus merge in the commit-graph file, we store the first parent in the normal place, but use the second parent position to point into the "extra edges" chunk where the remaining parents exist. This means we should be adding "num_parents - 1" edges to this list, not "num_parents - 2". That is the basic error. The reason this was not caught in the test suite is more subtle. In 5324-split-commit-graph.sh, we test creating an octopus merge and adding it to the tip of a commit-graph chain, then verify the result. This _should_ have caught the problem, except that when we load the commit-graph files we were overly careful to not fail when the commit-graph chain does not match. This care was on purpose to avoid race conditions as one process reads the chain and another process modifies it. In such a case, the reading process outputs the following message to stderr: warning: commit-graph chain does not match These warnings are output in the test suite, but ignored. By checking the stderr of `git commit-graph verify` to include the expected progress output, it will now catch this error. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02Merge branch 'jc/log-mailmap-flip-defaults'Libravatar Junio C Hamano2-2/+33
Hotfix for making "git log" use the mailmap by default. * jc/log-mailmap-flip-defaults: log: really flip the --mailmap default log: flip the --mailmap default unconditionally
2019-08-02Merge branch 'js/early-config-with-onbranch'Libravatar Junio C Hamano1-0/+5
The recently added [includeif "onbranch:branch"] feature does not work well with an early config mechanism, as it attempts to find out what branch we are on before we even haven't located the git repository. The inclusion during early config scan is ignored to work around this issue. * js/early-config-with-onbranch: config: work around bug with includeif:onbranch and early config
2019-08-02log: really flip the --mailmap defaultLibravatar Junio C Hamano1-0/+33
Update the docs, test the interaction between the new default, configuration and command line option, in addition to actually flipping the default. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-01Merge branch 'jk/repack-silence-auto-bitmap-warning'Libravatar Junio C Hamano1-1/+14
Squelch unneeded and misleading warnings from "repack" when the command attempts to generate pack bitmaps without explicitly asked for by the user. * jk/repack-silence-auto-bitmap-warning: repack: simplify handling of auto-bitmaps and .keep files repack: silence warnings when auto-enabled bitmaps cannot be built t7700: clean up .keep file in bitmap-writing test
2019-08-01Merge branch 'jk/sort-iter-test-output'Libravatar Junio C Hamano2-33/+55
* jk/sort-iter-test-output: t: sort output of hashmap iteration
2019-08-01Merge branch 'jc/dir-iterator-test-fix'Libravatar Junio C Hamano2-3/+12
* jc/dir-iterator-test-fix: test-dir-iterator: do not assume errno values
2019-08-01Merge branch 'bc/hash-independent-tests-part-4'Libravatar Junio C Hamano11-93/+142
Update to the tests to help SHA-256 transition continues. * bc/hash-independent-tests-part-4: t2203: avoid hard-coded object ID values t1710: make hash independent t1007: remove SHA1 prerequisites t0090: make test pass with SHA-256 t0027: make hash size independent t6030: make test work with SHA-256 t5000: make hash independent t1450: make hash size independent t1410: make hash size independent t: add helper to convert object IDs to paths
2019-08-01log: flip the --mailmap default unconditionallyLibravatar Junio C Hamano1-2/+0
It turns out that being cautious to warn against upcoming default change was an unpopular behaviour, and such a care can easily be defeated by distro packagers to render it ineffective anyway. Just flip the default, with only a mention in the release notes. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31config: work around bug with includeif:onbranch and early configLibravatar Johannes Schindelin1-0/+5
Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition, 2019-06-05), there is a potential catch-22 in the early config path: if the `include.onbranch:` feature is used, Git assumes that the Git directory has been initialized already. However, in the early config code path that is not true. One way to trigger this is to call the following commands in any repository: git config includeif.onbranch:refs/heads/master.path broken git help -a The symptom triggered by the `git help -a` invocation reads like this: BUG: refs.c:1851: attempting to get main_ref_store outside of repository Let's work around this, simply by ignoring the `includeif.onbranch:` setting when parsing the config when the ref store has not been initialized (yet). Technically, there is a way to solve this properly: teach the refs machinery to initialize the ref_store from a given gitdir/commondir pair (which we _do_ have in the early config code path), and then use that in `include_by_branch()`. This, however, is a pretty involved project, and we're already in the feature freeze for Git v2.23.0. Note: when calling above-mentioned two commands _outside_ of any Git worktree (passing the `--global` flag to `git config`, as there is obviously no repository config available), at the point when `include_by_branch()` is called, `the_repository` is `NULL`, therefore we have to be extra careful not to dereference it in that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31repack: simplify handling of auto-bitmaps and .keep filesLibravatar Jeff King1-1/+2
Commit 7328482253 (repack: disable bitmaps-by-default if .keep files exist, 2019-06-29) taught repack to prefer disabling bitmaps to duplicating objects (unless bitmaps were asked for explicitly). But there's an easier way to do this: if we keep passing the --honor-pack-keep flag to pack-objects when auto-enabling bitmaps, then pack-objects already makes the same decision (it will disable bitmaps rather than duplicate). Better still, pack-objects can actually decide to do so based not just on the presence of a .keep file, but on whether that .keep file actually impacts the new pack we're making (so if we're racing with a push or fetch, for example, their temporary .keep file will not block us from generating bitmaps if they haven't yet updated their refs). And because repack uses the --write-bitmap-index-quiet flag, we don't have to worry about pack-objects generating confusing warnings when it does see a .keep file. We can confirm this by tweaking the .keep test to check repack's stderr. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31repack: silence warnings when auto-enabled bitmaps cannot be builtLibravatar Jeff King1-0/+11
Depending on various config options, a full repack may not be able to build a reachability bitmap index (e.g., if pack.packSizeLimit forces us to write multiple packs). In these cases pack-objects may write a warning to stderr. Since 36eba0323d (repack: enable bitmaps by default on bare repos, 2019-03-14), we may generate these warnings even when the user did not explicitly ask for bitmaps. This has two downsides: - it can be confusing, if they don't know what bitmaps are - a daemonized auto-gc will write this to its log file, and the presence of the warning may suppress further auto-gc (until gc.logExpiry has elapsed) Let's have repack communicate to pack-objects that the choice to turn on bitmaps was not made explicitly by the user, which in turn allows pack-objects to suppress these warnings. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31t7700: clean up .keep file in bitmap-writing testLibravatar Jeff King1-0/+1
After our test snippet finishes, the .keep file is left in place, making it hard to do further tests of the auto-bitmap-writing code (since it suppresses the feature completely). Let's clean it up. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-31t: sort output of hashmap iterationLibravatar Jeff King2-33/+55
The iteration order of a hashmap is undefined, and may depend on things like the exact set of items added, or the table has been grown or shrunk. In the case of an oidmap, it even depends on endianness, because we take the oid hash by casting sha1 bytes directly into an unsigned int. Let's sort the test-tool output from any hash iterators. In the case of t0011, this is just future-proofing. But for t0016, it actually fixes a reported failure on the big-endian s390 and nonstop ports. I didn't bother to teach the helper functions to optionally sort output. They are short enough that it's simpler to just repeat them inline for the iteration tests than it is to add a --sort option. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-30test-dir-iterator: do not assume errno valuesLibravatar Junio C Hamano2-3/+12
A few tests printed 'errno' as an integer and compared with hardcoded integers; this is obviously not portable. A two things to note are: - the string obtained by strerror() is not portable, and cannot be used for the purpose of these tests. - there unfortunately isn't a portable way to map error numbers to error names. As we only care about a few selected errors, just map the error number to the name before emitting for comparison. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Merge branch 'jk/xdiff-clamp-funcname-context-index'Libravatar Junio C Hamano1-0/+22
The internal diff machinery can be made to read out of bounds while looking for --funcion-context line in a corner case, which has been corrected. * jk/xdiff-clamp-funcname-context-index: xdiff: clamp function context indices in post-image
2019-07-29Merge branch 'fc/fetch-with-import-fix' into maintLibravatar Junio C Hamano2-13/+27
Code restructuring during 2.20 period broke fetching tags via "import" based transports. * fc/fetch-with-import-fix: fetch: fix regression with transport helpers fetch: make the code more understandable fetch: trivial cleanup t5801 (remote-helpers): add test to fetch tags t5801 (remote-helpers): cleanup refspec stuff
2019-07-29Merge branch 'ds/close-object-store' into maintLibravatar Junio C Hamano1-0/+8
The commit-graph file is now part of the "files that the runtime may keep open file descriptors on, all of which would need to be closed when done with the object store", and the file descriptor to an existing commit-graph file now is closed before "gc" finalizes a new instance to replace it. * ds/close-object-store: packfile: rename close_all_packs to close_object_store packfile: close commit-graph in close_all_packs commit-graph: use raw_object_store when closing commit-graph: extract write_commit_graph_file() commit-graph: extract copy_oids_to_commits() commit-graph: extract count_distinct_commits() commit-graph: extract fill_oids_from_all_packs() commit-graph: extract fill_oids_from_commit_hex() commit-graph: extract fill_oids_from_packs() commit-graph: create write_commit_graph_context commit-graph: remove Future Work section commit-graph: collapse parameters into flags commit-graph: return with errors during write commit-graph: fix the_repository reference
2019-07-29Merge branch 'pw/add-p-recount' into maintLibravatar Junio C Hamano1-0/+8
"git checkout -p" needs to selectively apply a patch in reverse, which did not work well. * pw/add-p-recount: add -p: fix checkout -p with pathological context
2019-07-29Merge branch 'jk/trailers-use-config' into maintLibravatar Junio C Hamano1-27/+44
"git interpret-trailers" always treated '#' as the comment character, regardless of core.commentChar setting, which has been corrected. * jk/trailers-use-config: interpret-trailers: load default config
2019-07-29Merge branch 'tg/stash-ref-by-index-fix' into maintLibravatar Junio C Hamano1-0/+18
"git stash show 23" used to work, but no more after getting rewritten in C; this regression has been corrected. * tg/stash-ref-by-index-fix: stash: fix show referencing stash index
2019-07-29Merge branch 'pw/rebase-abort-clean-rewritten' into maintLibravatar Junio C Hamano1-1/+17
"git rebase --abort" used to leave refs/rewritten/ when concluding "git rebase -r", which has been corrected. * pw/rebase-abort-clean-rewritten: rebase --abort/--quit: cleanup refs/rewritten sequencer: return errors from sequencer_remove_state() rebase: warn if state directory cannot be removed rebase: fix a memory leak
2019-07-29Merge branch 'sg/rebase-progress' into maintLibravatar Junio C Hamano3-75/+55
Use "Erase in Line" CSI sequence that is already used in the editor support to clear cruft in the progress output. * sg/rebase-progress: progress: use term_clear_line() rebase: fix garbled progress display with '-x' pager: add a helper function to clear the last line in the terminal t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused t3404: modernize here doc style
2019-07-29Merge branch 'ms/submodule-foreach-fix' into maintLibravatar Junio C Hamano1-0/+7
"git submodule foreach" did not protect command line options passed to the command to be run in each submodule correctly, when the "--recursive" option was in use. * ms/submodule-foreach-fix: submodule foreach: fix recursion of options
2019-07-29Merge branch 'js/rebase-reschedule-applies-only-to-interactive' into maintLibravatar Junio C Hamano1-0/+8
The configuration variable rebase.rescheduleFailedExec should be effective only while running an interactive rebase and should not affect anything when running an non-interactive one, which was not the case. This has been corrected. * js/rebase-reschedule-applies-only-to-interactive: rebase --am: ignore rebase.rescheduleFailedExec
2019-07-29Merge branch 'jc/denoise-rm-to-resolve' into maintLibravatar Junio C Hamano1-0/+13
"git rm" to resolve a conflicted path leaked an internal message "needs merge" before actually removing the path, which was confusing. This has been corrected. * jc/denoise-rm-to-resolve: rm: resolving by removal is not a warning-worthy event
2019-07-29Merge branch 'js/mingw-spawn-with-spaces-in-path' into maintLibravatar Junio C Hamano1-0/+6
Window 7 update ;-) * js/mingw-spawn-with-spaces-in-path: mingw: support spawning programs containing spaces in their names
2019-07-29Merge branch 'js/clean-report-too-long-a-path' into maintLibravatar Junio C Hamano1-0/+12
"git clean" silently skipped a path when it cannot lstat() it; now it gives a warning. * js/clean-report-too-long-a-path: clean: show an error message when the path is too long
2019-07-29Merge branch 'es/local-atomic-push-failure-with-http' into maintLibravatar Junio C Hamano1-0/+49
"git push --atomic" that goes over the transport-helper (namely, the smart http transport) failed to prevent refs to be pushed when it can locally tell that one of the ref update will fail without having to consult the other end, which has been corrected. * es/local-atomic-push-failure-with-http: transport-helper: avoid var decl in for () loop control transport-helper: enforce atomic in push_refs_with_push
2019-07-29Merge branch 'js/t3404-typofix' into maintLibravatar Junio C Hamano1-1/+1
Typofix. * js/t3404-typofix: t3404: fix a typo
2019-07-29Merge branch 'js/t0001-case-insensitive' into maintLibravatar Junio C Hamano2-14/+23
Test update. * js/t0001-case-insensitive: t0001: fix on case-insensitive filesystems
2019-07-29Merge branch 'sg/t5551-fetch-smart-error-is-translated' into maintLibravatar Junio C Hamano1-2/+2
Test update. * sg/t5551-fetch-smart-error-is-translated: t5551: use 'test_i18ngrep' to check translated output
2019-07-29Merge branch 'jt/t5551-test-chunked' into maintLibravatar Junio C Hamano1-3/+2
Update smart-http test. * jt/t5551-test-chunked: t5551: test usage of chunked encoding explicitly
2019-07-25Merge branch 'sw/git-p4-unshelve-branched-files' into maintLibravatar Junio C Hamano1-1/+7
"git p4" update. * sw/git-p4-unshelve-branched-files: git-p4: allow unshelving of branched files
2019-07-25Merge branch 'jt/partial-clone-missing-ref-delta-base' into maintLibravatar Junio C Hamano1-13/+99
"git fetch" into a lazy clone forgot to fetch base objects that are necessary to complete delta in a thin packfile, which has been corrected. * jt/partial-clone-missing-ref-delta-base: t5616: cover case of client having delta base t5616: use correct flag to check object is missing index-pack: prefetch missing REF_DELTA bases t5616: refactor packfile replacement
2019-07-25Merge branch 'xl/record-partial-clone-origin' into maintLibravatar Junio C Hamano1-3/+13
When creating a partial clone, the object filtering criteria is recorded for the origin of the clone, but this incorrectly used a hardcoded name "origin" to name that remote; it has been corrected to honor the "--origin <name>" option. * xl/record-partial-clone-origin: clone: respect user supplied origin name when setting up partial clone
2019-07-25Merge branch 'pb/request-pull-verify-remote-ref' into maintLibravatar Junio C Hamano1-0/+53
"git request-pull" learned to warn when the ref we ask them to pull from in the local repository and in the published repository are different. * pb/request-pull-verify-remote-ref: request-pull: warn if the remote object is not the same as the local one request-pull: quote regex metacharacters in local ref
2019-07-25Merge branch 'vv/merge-squash-with-explicit-commit' into maintLibravatar Junio C Hamano1-0/+6
"git merge --squash" is designed to update the working tree and the index without creating the commit, and this cannot be countermanded by adding the "--commit" option; the command now refuses to work when both options are given. * vv/merge-squash-with-explicit-commit: merge: refuse --commit with --squash
2019-07-25Merge branch 'js/bundle-verify-require-object-store' into maintLibravatar Junio C Hamano1-0/+6
"git bundle verify" needs to see if prerequisite objects exist in the receiving repository, but the command did not check if we are in a repository upfront, which has been corrected. * js/bundle-verify-require-object-store: bundle verify: error out if called without an object database
2019-07-25Merge branch 'jk/am-i-resolved-fix' into maintLibravatar Junio C Hamano1-0/+52
"git am -i --resolved" segfaulted after trying to see a commit as if it were a tree, which has been corrected. * jk/am-i-resolved-fix: am: fix --interactive HEAD tree resolution am: drop tty requirement for --interactive am: read interactive input from stdin am: simplify prompt response handling
2019-07-25Merge branch 'jk/HEAD-symref-in-xfer-namespaces' into maintLibravatar Junio C Hamano1-0/+28
The server side support for "git fetch" used to show incorrect value for the HEAD symbolic ref when the namespace feature is in use, which has been corrected. * jk/HEAD-symref-in-xfer-namespaces: upload-pack: strip namespace from symref data