summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2017-02-03Merge branch 'cw/log-updates-for-all-refs-really'Libravatar Junio C Hamano2-7/+81
The "core.logAllRefUpdates" that used to be boolean has been enhanced to take 'always' as well, to record ref updates to refs other than the ones that are expected to be updated (i.e. branches, remote-tracking branches and notes). * cw/log-updates-for-all-refs-really: doc: add note about ignoring '--no-create-reflog' update-ref: add test cases for bare repository refs: add option core.logAllRefUpdates = always config: add markup to core.logAllRefUpdates doc
2017-02-03Merge branch 'js/re-running-failed-tests'Libravatar Junio C Hamano1-0/+6
"make -C t failed" will now run only the tests that failed in the previous run. This is usable only when prove is not use, and gives a useless error message when run after "make clean", but otherwise is serviceable. * js/re-running-failed-tests: t/Makefile: add a rule to re-run previously-failed tests
2017-02-03Merge branch 'sb/submodule-update-initial-runs-custom-script'Libravatar Junio C Hamano1-0/+12
The user can specify a custom update method that is run when "submodule update" updates an already checked out submodule. This was ignored when checking the submodule out for the first time and we instead always just checked out the commit that is bound to the path in the superproject's index. * sb/submodule-update-initial-runs-custom-script: submodule update: run custom update script for initial populating as well
2017-02-03Merge branch 'sb/submodule-recursive-absorb'Libravatar Junio C Hamano1-0/+27
When a submodule "A", which has another submodule "B" nested within it, is "absorbed" into the top-level superproject, the inner submodule "B" used to be left in a strange state. The logic to adjust the .git pointers in these submodules has been corrected. * sb/submodule-recursive-absorb: submodule absorbing: fix worktree/gitdir pointers recursively for non-moves cache.h: expose the dying procedure for reading gitlinks setup: add gentle version of resolve_git_dir
2017-02-03Merge branch 'sb/unpack-trees-super-prefix'Libravatar Junio C Hamano2-654/+643
"git read-tree" and its underlying unpack_trees() machinery learned to report problematic paths prefixed with the --super-prefix option. * sb/unpack-trees-super-prefix: unpack-trees: support super-prefix option t1001: modernize style t1000: modernize style read-tree: use OPT_BOOL instead of OPT_SET_INT
2017-02-02Merge branch 'nd/log-graph-configurable-colors'Libravatar Junio C Hamano3-1/+42
Some people feel the default set of colors used by "git log --graph" rather limiting. A mechanism to customize the set of colors has been introduced. * nd/log-graph-configurable-colors: document behavior of empty color name color_parse_mem: allow empty color spec log --graph: customize the graph lines with config log.graphColors color.c: trim leading spaces in color_parse_mem() color.c: fix color_parse_mem() with value_len == 0
2017-02-02Merge branch 'mm/reset-facl-before-umask-test'Libravatar Junio C Hamano1-0/+3
Test tweaks for those who have default ACL in their git source tree that interfere with the umask test. * mm/reset-facl-before-umask-test: t0001: don't let a default ACL interfere with the umask test
2017-02-02Merge branch 'js/unzip-in-usr-bin-workaround'Libravatar Junio C Hamano1-1/+3
Test tweak for FreeBSD where /usr/bin/unzip is unsuitable to run our tests but /usr/local/bin/unzip is usable. * js/unzip-in-usr-bin-workaround: test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/
2017-02-02Merge branch 'js/status-pre-rebase-i'Libravatar Junio C Hamano1-0/+19
After starting "git rebase -i", which first opens the user's editor to edit the series of patches to apply, but before saving the contents of that file, "git status" failed to show the current state (i.e. you are in an interactive rebase session, but you have applied no steps yet) correctly. * js/status-pre-rebase-i: status: be prepared for not-yet-started interactive rebase
2017-02-02Merge branch 'sb/submodule-add-force'Libravatar Junio C Hamano1-0/+14
"git submodule add" used to be confused and refused to add a locally created repository; users can now use "--force" option to add them. * sb/submodule-add-force: submodule add: extend force flag to add existing repos
2017-01-31color_parse_mem: allow empty color specLibravatar Jeff King3-2/+21
Prior to c2f41bf52 (color.c: fix color_parse_mem() with value_len == 0, 2017-01-19), the empty string was interpreted as a color "reset". This was an accidental outcome, and that commit turned it into an error. However, scripts may pass the empty string as a default value to "git config --get-color" to disable color when the value is not defined. The git-add--interactive script does this. As a result, the script is unusable since c2f41bf52 unless you have color.diff.plain defined (if it is defined, then we don't parse the empty default at all). Our test scripts didn't notice the recent breakage because they run without a terminal, and thus without color. They never hit this code path at all. And nobody noticed the original buggy "reset" behavior, because it was effectively a noop. Let's fix the code to have an empty color name produce an empty sequence of color codes. The tests need a few fixups: - we'll add a new test in t4026 to cover this case. But note that we need to tweak the color() helper. While we're there, let's factor out the literal ANSI ESC character. Otherwise it makes the diff quite hard to read. - we'll add a basic sanity-check in t4026 that "git add -p" works at all when color is enabled. That would have caught this bug, as well as any others that are specific to the color code paths. - 73c727d69 (log --graph: customize the graph lines with config log.graphColors, 2017-01-19) added a test to t4202 that checks some "invalid" graph color config. Since ",, blue" before yielded only "blue" as valid, and now yields "empty, empty, blue", we don't match the expected output. One way to fix this would be to change the expectation to the empty color strings. But that makes the test much less interesting, since we show only two graph lines, both of which would be colorless. Since the empty-string case is now covered by t4026, let's remove them entirely here. They're just in the way of the primary thing the test is supposed to be checking. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31Merge branch 'jk/fsck-connectivity-check-fix'Libravatar Junio C Hamano1-3/+73
"git fsck --connectivity-check" was not working at all. * jk/fsck-connectivity-check-fix: fsck: lazily load types under --connectivity-only fsck: move typename() printing to its own function t1450: use "mv -f" within loose object directory fsck: check HAS_OBJ more consistently fsck: do not fallback "git fsck <bogus>" to "git fsck" fsck: tighten error-checks of "git fsck <head>" fsck: prepare dummy objects for --connectivity-check fsck: report trees as dangling t1450: clean up sub-objects in duplicate-entry test
2017-01-31Merge branch 'js/difftool-builtin'Libravatar Junio C Hamano1-46/+46
Rewrite a scripted porcelain "git difftool" in C. * js/difftool-builtin: difftool: hack around -Wzero-length-format warning difftool: retire the scripted version difftool: implement the functionality in the builtin difftool: add a skeleton for the upcoming builtin
2017-01-31Merge branch 'rs/qsort-s'Libravatar Junio C Hamano2-0/+51
A few codepaths had to rely on a global variable when sorting elements of an array because sort(3) API does not allow extra data to be passed to the comparison function. Use qsort_s() when natively available, and a fallback implementation of it when not, to eliminate the need, which is a prerequisite for making the codepath reentrant. * rs/qsort-s: ref-filter: use QSORT_S in ref_array_sort() string-list: use QSORT_S in string_list_sort() perf: add basic sort performance test add QSORT_S compat: add qsort_s()
2017-01-31Merge branch 'vp/show-ref-verify-head'Libravatar Junio C Hamano1-0/+42
"git show-ref HEAD" used with "--verify" because the user is not interested in seeing refs/remotes/origin/HEAD, and used with "--head" because the user does not want HEAD to be filtered out, i.e. "git show-ref --head --verify HEAD", did not work as expected. * vp/show-ref-verify-head: show-ref: remove a stale comment show-ref: remove dead `if (verify)' check show-ref: detect dangling refs under --verify as well show-ref: move --quiet handling into show_one() show-ref: allow -d to work with --verify show-ref: accept HEAD with --verify
2017-01-31Merge branch 'js/remote-rename-with-half-configured-remote'Libravatar Junio C Hamano1-0/+7
With anticipatory tweaking for remotes defined in ~/.gitconfig (e.g. "remote.origin.prune" set to true, even though there may or may not actually be "origin" remote defined in a particular Git repository), "git remote rename" and other commands misinterpreted and behaved as if such a non-existing remote actually existed. * js/remote-rename-with-half-configured-remote: remote rename: more carefully determine whether a remote is configured remote rename: demonstrate a bogus "remote exists" bug
2017-01-31Merge branch 'st/verify-tag'Libravatar Junio C Hamano2-0/+32
"git tag" and "git verify-tag" learned to put GPG verification status in their "--format=<placeholders>" output format. * st/verify-tag: t/t7004-tag: Add --format specifier tests t/t7030-verify-tag: Add --format specifier tests builtin/tag: add --format argument for tag -v builtin/verify-tag: add --format to verify-tag ref-filter: add function to print single ref_array_item gpg-interface, tag: add GPG_VERIFY_OMIT_STATUS flag
2017-01-31Merge branch 'js/sequencer-i-countdown-3'Libravatar Junio C Hamano1-0/+16
The sequencer machinery has been further enhanced so that a later set of patches can start using it to reimplement "rebase -i". * js/sequencer-i-countdown-3: (38 commits) sequencer (rebase -i): write out the final message sequencer (rebase -i): write the progress into files sequencer (rebase -i): show the progress sequencer (rebase -i): suggest --edit-todo upon unknown command sequencer (rebase -i): show only failed cherry-picks' output sequencer (rebase -i): show only failed `git commit`'s output sequencer: use run_command() directly sequencer: update reading author-script sequencer (rebase -i): differentiate between comments and 'noop' sequencer (rebase -i): implement the 'drop' command sequencer (rebase -i): allow rescheduling commands sequencer (rebase -i): respect strategy/strategy_opts settings sequencer (rebase -i): respect the rebase.autostash setting sequencer (rebase -i): run the post-rewrite hook, if needed sequencer (rebase -i): record interrupted commits in rewritten, too sequencer (rebase -i): copy commit notes at end sequencer (rebase -i): set the reflog message consistently sequencer (rebase -i): refactor setting the reflog message sequencer (rebase -i): allow fast-forwarding for edit/reword sequencer (rebase -i): implement the 'reword' command ...
2017-01-31Merge branch 'jk/loose-object-fsck'Libravatar Junio C Hamano1-12/+74
"git fsck" inspects loose objects more carefully now. * jk/loose-object-fsck: fsck: detect trailing garbage in all object types fsck: parse loose object paths directly sha1_file: add read_loose_object() function t1450: test fsck of packed objects sha1_file: fix error message for alternate objects t1450: refactor loose-object removal
2017-01-31Merge branch 'bw/push-submodule-only'Libravatar Junio C Hamano1-0/+21
"git submodule push" learned "--recurse-submodules=only option to push submodules out without pushing the top-level superproject. * bw/push-submodule-only: push: add option to push only submodules submodules: add RECURSE_SUBMODULES_ONLY value transport: reformat flag #defines to be more readable
2017-01-31update-ref: add test cases for bare repositoryLibravatar Cornelius Weig1-7/+36
The default behavior of update-ref to create reflogs differs in repositories with worktree and bare ones. The existing tests cover only the behavior of repositories with worktree. This commit adds tests that assert the correct behavior in bare repositories for update-ref. Two cases are covered: - If core.logAllRefUpdates is not set, no reflogs should be created - If core.logAllRefUpdates is true, reflogs should be created Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31refs: add option core.logAllRefUpdates = alwaysLibravatar Cornelius Weig2-0/+45
When core.logallrefupdates is true, we only create a new reflog for refs that are under certain well-known hierarchies. The reason is that we know that some hierarchies (like refs/tags) are not meant to change, and that unknown hierarchies might not want reflogs at all (e.g., a hypothetical refs/foo might be meant to change often and drop old history immediately). However, sometimes it is useful to override this decision and simply log for all refs, because the safety and audit trail is more important than the performance implications of keeping the log around. This patch introduces a new "always" mode for the core.logallrefupdates option which will log updates to everything under refs/, regardless where in the hierarchy it is (we still will not log things like ORIG_HEAD and FETCH_HEAD, which are known to be transient). Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-30t0001: don't let a default ACL interfere with the umask testLibravatar Matt McCutchen1-0/+3
The "init creates a new deep directory (umask vs. shared)" test expects the permissions of newly created files to be based on the umask, which fails if a default ACL is inherited from the working tree for git. So attempt to remove a default ACL if there is one. Same idea as 8ed0a740dd42bd0724aebed6e3b07c4ea2a2d5e8. (I guess I'm the only one who ever runs the test suite with a default ACL set.) Signed-off-by: Matt McCutchen <matt@mattmccutchen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-27test-lib: on FreeBSD, look for unzip(1) in /usr/local/bin/Libravatar Johannes Schindelin1-1/+3
Eric Wong reported that while FreeBSD has a /usr/bin/unzip, it uses different semantics from those that are needed by Git's tests: When passing the -a option to Info-Zip, it heeds the text attribute of the .zip file's central directory, while FreeBSD's unzip ignores that attribute. The common work-around is to install Info-Zip on FreeBSD, into /usr/local/bin/. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Tested-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-27t/Makefile: add a rule to re-run previously-failed testsLibravatar Johannes Schindelin1-0/+6
This patch automates the process of determining which tests failed previously and re-running them. While developing patch series, it is a good practice to run the test suite from time to time, just to make sure that obvious bugs are caught early. With complex patch series, it is common to run `make -j15 -k test`, i.e. run the tests in parallel and *not* stop at the first failing test but continue. This has the advantage of identifying possibly multiple problems in one big test run. It is particularly important to reduce the turn-around time thusly on Windows, where the test suite spends 45 minutes on the computer on which this patch was developed. It is the most convenient way to determine which tests failed after running the entire test suite, in parallel, to look for left-over "trash directory.t*" subdirectories in the t/ subdirectory. However, those directories might live outside t/ when overridden using the --root=<directory> option, to which the Makefile has no access. The next best method is to grep explicitly for failed tests in the test-results/ directory, which the Makefile *can* access. Please note that the often-recommended `prove` tool requires Perl, and that opens a whole new can of worms on Windows. As no native Windows Perl comes with Subversion bindings, we have to use a Perl in Git for Windows that uses the POSIX emulation layer named MSYS2 (which is a portable version of Cygwin). When using this emulation layer under stress, e.g. when running massively-parallel tests, unexplicable crashes occur quite frequently, and instead of having a solution to the original problem, the developer now has an additional, quite huge problem. For that reason, this developer rejected `prove` as a solution and went with this patch instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26status: be prepared for not-yet-started interactive rebaseLibravatar Johannes Schindelin1-0/+19
Some developers might want to call `git status` in a working directory where they just started an interactive rebase, but the edit script is still opened in the editor. Let's show a meaningful message in such cases. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26submodule update: run custom update script for initial populating as wellLibravatar Stefan Beller1-0/+12
In 1b4735d9f3 (submodule: no [--merge|--rebase] when newly cloned, 2011-02-17), all actions were defaulted to checkout for populating a submodule initially, because merging or rebasing makes no sense in that situation. Other commands however do make sense, such as the custom command that was added later (6cb5728c43, submodule update: allow custom command to update submodule working tree, 2013-07-03). I am unsure about the "none" command, as I can see an initial checkout there as a useful thing. On the other hand going strictly by our own documentation, we should do nothing in case of "none" as well, because the user asked for it. Reported-by: Han-Wen Nienhuys <hanwen@google.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-26submodule absorbing: fix worktree/gitdir pointers recursively for non-movesLibravatar Stefan Beller1-0/+27
Consider having a submodule 'sub' and a nested submodule at 'sub/nested'. When nested is already absorbed into sub, but sub is not absorbed into its superproject, then we need to fixup the gitfile and core.worktree setting for 'nested' when absorbing 'sub', but we do not need to move its git dir around. Previously 'nested's gitfile contained "gitdir: ../.git/modules/nested"; it has to be corrected to "gitdir: ../../.git/modules/sub1/modules/nested". An alternative I considered to do this work lazily, i.e. when resolving "../.git/modules/nested", we would notice the ".git" being a gitfile linking to another path. That seemed to be robuster by design, but harder to get the implementation right. Maybe we have to do that anyway once we try to have submodules and worktrees working nicely together, but for now just produce 'correct' (i.e. direct) pointers. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-25unpack-trees: support super-prefix optionLibravatar Stefan Beller1-0/+8
In the future we want to support working tree operations within submodules, e.g. "git checkout --recurse-submodules", which will update the submodule to the commit as recorded in its superproject. In the submodule the unpack-tree operation is carried out as usual, but the reporting to the user needs to prefix any path with the superproject. The mechanism for this is the super-prefix. (see 74866d757, git: make super-prefix option) Add support for the super-prefix option for commands that unpack trees by wrapping any path output in unpacking trees in the newly introduced super_prefixed function. This new function prefixes any path with the super-prefix if there is one. Assuming the submodule case doesn't happen in the majority of the cases, we'd want to have a fast behavior for no super prefix, i.e. no reallocation/copying, but just returning path. Another aspect of introducing the `super_prefixed` function is to consider who owns the memory and if this is the right place where the path gets modified. As the super prefix ought to change the output behavior only and not the actual unpack tree part, it is fine to be that late in the line. As we get passed in 'const char *path', we cannot change the path itself, which means in case of a super prefix we have to copy over the path. We need two static buffers in that function as the error messages contain at most two paths. For testing purposes enable it in read-tree, which has no output of paths other than an unpack-trees.c. These are all converted in this patch. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-25t1450: use "mv -f" within loose object directoryLibravatar Jeff King1-1/+1
The loose objects are created with mode 0444. That doesn't prevent them being overwritten by rename(), but some versions of "mv" will be extra careful and prompt the user, even without "-i". Reportedly macOS does this, at least in the Travis builds. The prompt reads from /dev/null, defaulting to "no", and the object isn't moved. Then to make matters even more interesting, it still returns "0" and the rest of the test proceeds, but with a broken setup. We can work around it by using "mv -f" to override the prompt. This should work as it's already used in t5504 for the same purpose. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23log --graph: customize the graph lines with config log.graphColorsLibravatar Nguyễn Thái Ngọc Duy1-0/+22
If you have a 256 colors terminal (or one with true color support), then the predefined 12 colors seem limited. On the other hand, you don't want to draw graph lines with every single color in this mode because the two colors could look extremely similar. This option allows you to hand pick the colors you want. Even with standard terminal, if your background color is neither black or white, then the graph line may match your background and become hidden. You can exclude your background color (or simply the colors you hate) with this. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23Merge branch 'sb/cd-then-git-can-be-written-as-git-c'Libravatar Junio C Hamano1-4/+1
Test clean-up. * sb/cd-then-git-can-be-written-as-git-c: lib-submodule-update.sh: reduce use of subshell by using "git -C"
2017-01-23Merge branch 'sg/fix-versioncmp-with-common-suffix'Libravatar Junio C Hamano1-20/+112
The prereleaseSuffix feature of version comparison that is used in "git tag -l" did not correctly when two or more prereleases for the same release were present (e.g. when 2.0, 2.0-beta1, and 2.0-beta2 are there and the code needs to compare 2.0-beta1 and 2.0-beta2). * sg/fix-versioncmp-with-common-suffix: versioncmp: generalize version sort suffix reordering versioncmp: factor out helper for suffix matching versioncmp: use earliest-longest contained suffix to determine sorting order versioncmp: cope with common part overlapping with prerelease suffix versioncmp: pass full tagnames to swap_prereleases() t7004-tag: add version sort tests to show prerelease reordering issues t7004-tag: use test_config helper t7004-tag: delete unnecessary tags with test_when_finished
2017-01-23Merge branch 'vn/diff-ihc-config'Libravatar Junio C Hamano1-1/+26
"git diff" learned diff.interHunkContext configuration variable that gives the default value for its --inter-hunk-context option. * vn/diff-ihc-config: diff: add interhunk context config option
2017-01-23Merge branch 'sb/submodule-init'Libravatar Junio C Hamano1-0/+17
Error message fix. * sb/submodule-init: submodule update --init: display correct path from submodule
2017-01-23Merge branch 'sb/submodule-config-tests'Libravatar Junio C Hamano1-2/+23
Test updates. * sb/submodule-config-tests: t7411: test lookup of uninitialized submodules t7411: quote URLs
2017-01-23Merge branch 'jk/grep-e-could-be-extended-beyond-posix'Libravatar Junio C Hamano1-11/+15
Tighten a test to avoid mistaking an extended ERE regexp engine as a PRE regexp engine. * jk/grep-e-could-be-extended-beyond-posix: t7810: avoid assumption about invalid regex syntax
2017-01-23show-ref: detect dangling refs under --verify as wellLibravatar Vladimir Panteleev1-0/+22
Move detection of dangling refs into show_one(), so that they are detected when --verify is present as well as when it is absent. Signed-off-by: Vladimir Panteleev <git@thecybershadow.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23show-ref: allow -d to work with --verifyLibravatar Vladimir Panteleev1-0/+9
Move handling of -d into show_one(), so that it takes effect when --verify is present as well as when it is absent. This is useful when the user wishes to avoid the costly iteration of refs. Signed-off-by: Vladimir Panteleev <git@thecybershadow.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23show-ref: accept HEAD with --verifyLibravatar Vladimir Panteleev1-0/+11
Previously, when --verify was specified, show-ref would use a separate code path which did not handle HEAD and treated it as an invalid ref. Thus, "git show-ref --verify HEAD" (where "--verify" is used because the user is not interested in seeing refs/remotes/origin/HEAD) did not work as expected. Instead of insisting that the input begins with "refs/", allow "HEAD" as well in the codepath that handles "--verify", so that all valid full refnames including HEAD are passed to the same output machinery. Signed-off-by: Vladimir Panteleev <git@thecybershadow.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-23perf: add basic sort performance testLibravatar René Scharfe2-0/+51
Add a sort command to test-string-list that reads lines from stdin, stores them in a string_list and then sorts it. Use it in a simple perf test script to measure the performance of string_list_sort(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19remote rename: more carefully determine whether a remote is configuredLibravatar Johannes Schindelin1-1/+1
One of the really nice features of the ~/.gitconfig file is that users can override defaults by their own preferred settings for all of their repositories. One such default that some users like to override is whether the "origin" remote gets auto-pruned or not. The user would simply call git config --global remote.origin.prune true and from now on all "origin" remotes would be pruned automatically when fetching into the local repository. There is just one catch: now Git thinks that the "origin" remote is configured, even if the repository config has no [remote "origin"] section at all, as it does not realize that the "prune" setting was configured globally and that there really is no "origin" remote configured in this repository. That is a problem e.g. when renaming a remote to a new name, when Git may be fooled into thinking that there is already a remote of that new name. Let's fix this by paying more attention to *where* the remote settings came from: if they are configured in the local repository config, we must not overwrite them. If they were configured elsewhere, we cannot overwrite them to begin with, as we only write the repository config. There is only one caller of remote_is_configured() (in `git fetch`) that may want to take remotes into account even if they were configured outside the repository config; all other callers essentially try to prevent the Git command from overwriting settings in the repository config. To accommodate that fact, the remote_is_configured() function now requires a parameter that states whether the caller is interested in all remotes, or only in those that were configured in the repository config. Many thanks to Jeff King whose tireless review helped with settling for nothing less than the current strategy. This fixes https://github.com/git-for-windows/git/issues/888 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19remote rename: demonstrate a bogus "remote exists" bugLibravatar Johannes Schindelin1-0/+7
Some users like to set `remote.origin.prune = true` in their ~/.gitconfig so that all of their repositories use that default. However, our code is ill-prepared for this, mistaking that single entry to mean that there is already a remote of the name "origin", even if there is not. This patch adds a test case demonstrating this issue. Reported by Andrew Arnott. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-19difftool: retire the scripted versionLibravatar Johannes Schindelin1-48/+46
It served its purpose, but now we have a builtin difftool. Time for the Perl script to enjoy Florida. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-18Merge branch 'rh/mergetool-regression-fix'Libravatar Junio C Hamano1-114/+165
"git mergetool" without any pathspec on the command line that is run from a subdirectory became no-op in Git v2.11 by mistake, which has been fixed. * rh/mergetool-regression-fix: mergetool: fix running in subdir when rerere enabled mergetool: take the "-O" out of $orderfile t7610: add test case for rerere+mergetool+subdir bug t7610: spell 'git reset --hard' consistently t7610: don't assume the checked-out commit t7610: always work on a test-specific branch t7610: delete some now-unnecessary 'git reset --hard' lines t7610: run 'git reset --hard' after each test to clean up t7610: don't rely on state from previous test t7610: use test_when_finished for cleanup tasks t7610: move setup code to the 'setup' test case t7610: update branch names to match test number rev-parse doc: pass "--" to rev-parse in the --prefix example .mailmap: record canonical email for Richard Hansen
2017-01-18Merge branch 'sb/pathspec-errors'Libravatar Junio C Hamano1-0/+36
Running "git add a/b" when "a" is a submodule correctly errored out, but without a meaningful error message. * sb/pathspec-errors: pathspec: give better message for submodule related pathspec error
2017-01-18Merge branch 'pb/test-must-fail-is-for-git'Libravatar Junio C Hamano10-26/+26
Test cleanup. * pb/test-must-fail-is-for-git: t9813: avoid using pipes don't use test_must_fail with grep
2017-01-18Merge branch 'js/mingw-test-push-unc-path'Libravatar Junio C Hamano1-0/+48
"git push \\server\share\dir" has recently regressed and then fixed. A test has retroactively been added for this breakage. * js/mingw-test-push-unc-path: mingw: add a regression test for pushing to UNC paths
2017-01-18Merge branch 'km/branch-get-push-while-detached'Libravatar Junio C Hamano1-0/+6
"git <cmd> @{push}" on a detached HEAD used to segfault; it has been corrected to error out with a message. * km/branch-get-push-while-detached: branch_get_push: do not segfault when HEAD is detached
2017-01-18Merge branch 'jk/blame-fixes'Libravatar Junio C Hamano2-0/+149
"git blame --porcelain" misidentified the "previous" <commit, path> pair (aka "source") when contents came from two or more files. * jk/blame-fixes: blame: output porcelain "previous" header for each file blame: handle --no-abbrev blame: fix alignment with --abbrev=40