summaryrefslogtreecommitdiff
path: root/contrib
AgeCommit message (Collapse)AuthorFilesLines
2020-01-16msvc: accommodate for vcpkg's upgrade to OpenSSL v1.1.xLibravatar Johannes Schindelin1-2/+2
With the upgrade, the library names changed from libeay32/ssleay32 to libcrypto/libssl. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-23Merge branch 'nr/diff-highlight-indent-fix'Libravatar Junio C Hamano1-1/+1
Code cleanup. * nr/diff-highlight-indent-fix: diff-highlight: fix a whitespace nit
2019-10-23Merge branch 'mb/clarify-zsh-completion-doc'Libravatar Junio C Hamano1-2/+3
The installation instruction for zsh completion script (in contrib/) has been a bit improved. * mb/clarify-zsh-completion-doc: completion: clarify installation instruction for zsh
2019-10-18completion: clarify installation instruction for zshLibravatar Maxim Belsky1-2/+3
The original comment does not describe type of ~/.zsh/_git explicitly and zsh does not warn or fail if a user create it as a dictionary. So unexperienced users could be misled by the original comment. There is a small update to clarify it. Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Maxim Belsky <public.belsky@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15diff-highlight: fix a whitespace nitLibravatar Norman Rasmussen1-1/+1
This changes the indent from "<tab><sp><sp><sp><sp><sp><sp><sp><sp>" to "<tab><tab>" so that the statement lines up with the rest of the block. Signed-off-by: Norman Rasmussen <norman@rasmussen.co.za> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-15Merge branch 'ew/hashmap'Libravatar Junio C Hamano1-0/+16
Code clean-up of the hashmap API, both users and implementation. * ew/hashmap: hashmap_entry: remove first member requirement from docs hashmap: remove type arg from hashmap_{get,put,remove}_entry OFFSETOF_VAR macro to simplify hashmap iterators hashmap: introduce hashmap_free_entries hashmap: hashmap_{put,remove} return hashmap_entry * hashmap: use *_entry APIs for iteration hashmap_cmp_fn takes hashmap_entry params hashmap_get{,_from_hash} return "struct hashmap_entry *" hashmap: use *_entry APIs to wrap container_of hashmap_get_next returns "struct hashmap_entry *" introduce container_of macro hashmap_put takes "struct hashmap_entry *" hashmap_remove takes "const struct hashmap_entry *" hashmap_get takes "const struct hashmap_entry *" hashmap_add takes "struct hashmap_entry *" hashmap_get_next takes "const struct hashmap_entry *" hashmap_entry_init takes "struct hashmap_entry *" packfile: use hashmap_entry in delta_base_cache_entry coccicheck: detect hashmap_entry.hash assignment diff: use hashmap_entry_init on moved_entry.ent
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-0/+3
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-09Merge branch 'am/visual-studio-config-fix'Libravatar Junio C Hamano1-7/+8
Dev support. * am/visual-studio-config-fix: contrib/buildsystems: fix Visual Studio Debug configuration
2019-10-07Merge branch 'cc/svn-fe-py-shebang'Libravatar Junio C Hamano1-1/+1
* cc/svn-fe-py-shebang: contrib/svn-fe: fix shebang for svnrdump_sim.py
2019-10-07Merge branch 'hb/hg-to-git-py3'Libravatar Junio C Hamano1-25/+25
The hg-to-git script (in contrib/) has been updated to work with Python 3. * hb/hg-to-git-py3: hg-to-git: make it compatible with both python3 and python2
2019-10-07Merge branch 'mr/complete-more-for-log-etc'Libravatar Junio C Hamano1-4/+14
Completion updates. * mr/complete-more-for-log-etc: completion: add missing completions for log, diff, show
2019-10-07Merge branch 'dl/complete-rebase-and-archive'Libravatar Junio C Hamano1-19/+8
The command line completion for "git archive" and "git rebase" are now made less prone to go out of sync with the binary. * dl/complete-rebase-and-archive: completion: teach archive to use __gitcomp_builtin completion: teach rebase to use __gitcomp_builtin
2019-10-07coccicheck: detect hashmap_entry.hash assignmentLibravatar Eric Wong1-0/+16
Assigning hashmap_entry.hash manually leaves hashmap_entry.next uninitialized, which can be dangerous once the hashmap_entry is inserted into a hashmap. Detect those assignments and use hashmap_entry_init, instead. Signed-off-by: Eric Wong <e@80x24.org> Reviewed-by: Derrick Stolee <stolee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06vcxproj: only copy `git-remote-http.exe` once it was builtLibravatar Johannes Schindelin1-0/+3
In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-30Merge branch 'dl/rebase-i-keep-base'Libravatar Junio C Hamano1-1/+1
"git rebase --keep-base <upstream>" tries to find the original base of the topic being rebased and rebase on top of that same base, which is useful when running the "git rebase -i" (and its limited variant "git rebase -x"). The command also has learned to fast-forward in more cases where it can instead of replaying to recreate identical commits. * dl/rebase-i-keep-base: rebase: teach rebase --keep-base rebase tests: test linear branch topology rebase: fast-forward --fork-point in more cases rebase: fast-forward --onto in more cases rebase: refactor can_fast_forward into goto tower t3432: test for --no-ff's interaction with fast-forward t3432: distinguish "noop-same" v.s. "work-same" in "same head" tests t3432: test rebase fast-forward behavior t3431: add rebase --fork-point tests
2019-09-30Merge branch 'dl/complete-cherry-pick-revert-skip'Libravatar Junio C Hamano1-2/+4
The command line completion support (in contrib/) learned about the "--skip" option of "git revert" and "git cherry-pick". * dl/complete-cherry-pick-revert-skip: status: mention --skip for revert and cherry-pick completion: add --skip for cherry-pick and revert completion: merge options for cherry-pick and revert
2019-09-30Merge branch 'en/filter-branch-deprecation'Libravatar Junio C Hamano1-2/+2
Start discouraging the use of "git filter-branch". * en/filter-branch-deprecation: t9902: use a non-deprecated command for testing Recommend git-filter-repo instead of git-filter-branch t6006: simplify, fix, and optimize empty message test
2019-09-28contrib/buildsystems: fix Visual Studio Debug configurationLibravatar Alexandr Miloslavskiy1-7/+8
Even though Debug configuration builds, the resulting build is incorrect in a subtle way: it mixes up Debug and Release binaries, which in turn causes hard-to-predict bugs. In my case, when git calls iconv library, iconv sets 'errno' and git then tests it, but in Debug and Release CRT those 'errno' are different memory locations. This patch addresses 3 connected bugs: 1) Typo in '\(Configuration)'. As a result, Debug configuration condition is always false and Release path is taken instead. 2) Regexp that replaced 'zlib.lib' with 'zlibd.lib' was only affecting the first occurrence. However, some projects have it listed twice. Previously this bug was hidden, because Debug path was never taken. I decided that avoiding double -lz in makefile is fragile and I'd better replace all occurrences instead. 3) In Debug, 'libcurl-d.lib' should be used instead of 'libcurl.lib'. Previously this bug was hidden, because Debug path was never taken. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18hg-to-git: make it compatible with both python3 and python2Libravatar Hervé Beraud1-25/+25
Python 2 is EOL at the end of 2019, many distros and systems now come with python 3 as their default version. Rewrite features used in hg-to-git that are no longer supported in Python 3, in such a way that an updated code can still be usable with Python 2: - print is not a statement; use print() function instead. - dict.has_key(key) is no more; use "key in dict" instead. Signed-off-by: Hervé Beraud <herveberaud.pro@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-18contrib/svn-fe: fix shebang for svnrdump_sim.pyLibravatar Clément Chigot1-1/+1
The shebang for a python script should be "/usr/bin/env python" and not "/usr/bin/python". On some OSes like AIX, python default path is not under "/usr/bin" ("/opt/freeware/bin" for AIX). Note the main reason behind this change is that AIX rpm will add a dependency on "/usr/bin/python" instead of "/usr/bin/env". Signed-off-by: Clément Chigot <clement.chigot@atos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: teach archive to use __gitcomp_builtinLibravatar Denton Liu1-4/+1
Currently, _git_archive() uses a hardcoded list of options for its completion. However, we can use __gitcomp_builtin() to get a dynamically generated list of completions instead. Teach _git_archive() to use __gitcomp_builtin() so that newly implemented options in archive will be automatically completed without any mucking around in git-completion.bash. While we're at it, teach it to complete the missing `--worktree-attributes` option as well. Unfortunately, since some args are passed through from cmd_archive() to write_archive() (which calls parse_archive_args()), there's no way that a `--git-completion-helper` arg can end up reaching parse_archive_args() since the first call to parse_options() will end up calling exit(0). As a result, we have to carry the options supported by write_archive() in the hardcoded string. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: teach rebase to use __gitcomp_builtinLibravatar Denton Liu1-15/+7
Currently, _git_rebase() uses a hardcoded list of options for its completion. However, we can use __gitcomp_builtin() to get a dynamically generated list of completions instead. Teach _git_rebase() to use __gitcomp_builtin() so that newly implemented options in rebase will be automatically completed without any mucking around in git-completion.bash. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-12completion: add missing completions for log, diff, showLibravatar Max Rothman1-4/+14
The bash completion script knows some options to "git log" and "git show" only in the positive form, (e.g. "--abbrev-commit"), but not in their negative form (e.g. "--no-abbrev-commit"). Add them. Also, the bash completion script is missing some other options to "git diff", and "git show" (and thus, all other commands that take "git diff"'s options). Add them. Of note, since "--indent-heuristic" is no longer experimental, add that too. Signed-off-by: Max Rothman <max.r.rothman@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren1-2/+2
filter-branch suffers from a deluge of disguised dangers that disfigure history rewrites (i.e. deviate from the deliberate changes). Many of these problems are unobtrusive and can easily go undiscovered until the new repository is in use. This can result in problems ranging from an even messier history than what led folks to filter-branch in the first place, to data loss or corruption. These issues cannot be backward compatibly fixed, so add a warning to both filter-branch and its manpage recommending that another tool (such as filter-repo) be used instead. Also, update other manpages that referenced filter-branch. Several of these needed updates even if we could continue recommending filter-branch, either due to implying that something was unique to filter-branch when it applied more generally to all history rewriting tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because something about filter-branch was used as an example despite other more commonly known examples now existing. Reword these sections to fix these issues and to avoid recommending filter-branch. Finally, remove the section explaining BFG Repo Cleaner as an alternative to filter-branch. I feel somewhat bad about this, especially since I feel like I learned so much from BFG that I put to good use in filter-repo (which is much more than I can say for filter-branch), but keeping that section presented a few problems: * In order to recommend that people quit using filter-branch, we need to provide them a recomendation for something else to use that can handle all the same types of rewrites. To my knowledge, filter-repo is the only such tool. So it needs to be mentioned. * I don't want to give conflicting recommendations to users * If we recommend two tools, we shouldn't expect users to learn both and pick which one to use; we should explain which problems one can solve that the other can't or when one is much faster than the other. * BFG and filter-repo have similar performance * All filtering types that BFG can do, filter-repo can also do. In fact, filter-repo comes with a reimplementation of BFG named bfg-ish which provides the same user-interface as BFG but with several bugfixes and new features that are hard to implement in BFG due to its technical underpinnings. While I could still mention both tools, it seems like I would need to provide some kind of comparison and I would ultimately just say that filter-repo can do everything BFG can, so ultimately it seems that it is just better to remove that section altogether. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27rebase: teach rebase --keep-baseLibravatar Denton Liu1-1/+1
A common scenario is if a user is working on a topic branch and they wish to make some changes to intermediate commits or autosquash, they would run something such as git rebase -i --onto master... master in order to preserve the merge base. This is useful when contributing a patch series to the Git mailing list, one often starts on top of the current 'master'. While developing the patches, 'master' is also developed further and it is sometimes not the best idea to keep rebasing on top of 'master', but to keep the base commit as-is. In addition to this, a user wishing to test individual commits in a topic branch without changing anything may run git rebase -x ./test.sh master... master Since rebasing onto the merge base of the branch and the upstream is such a common case, introduce the --keep-base option as a shortcut. This allows us to rewrite the above as git rebase -i --keep-base master and git rebase -x ./test.sh --keep-base master respectively. Add tests to ensure --keep-base works correctly in the normal case and fails when there are multiple merge bases, both in regular and interactive mode. Also, test to make sure conflicting options cause rebase to fail. While we're adding test cases, add a missing set_fake_editor call to 'rebase -i --onto master...side'. While we're documenting the --keep-base option, change an instance of "merge-base" to "merge base", which is the consistent spelling. Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27completion: add --skip for cherry-pick and revertLibravatar Denton Liu1-1/+1
Even though `--skip` is a valid command-line option for cherry-pick and revert while they are in progress, it is not completed. Add this missing option to the completion script. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-27completion: merge options for cherry-pick and revertLibravatar Denton Liu1-2/+4
Since revert and cherry-pick share the same sequencer code, they should both accept the same command-line options. Derive the `__git_cherry_pick_inprogress_options` and `__git_revert_inprogress_options` variables from `__git_sequencer_inprogress_options` so that the options aren't unnecessarily duplicated twice. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete config variables and values for 'git clone --config='Libravatar SZEDER Gábor1-17/+49
Completing configuration sections and variable names for the stuck argument of 'git clone --config=<TAB>' requires a bit of extra care compared to doing the same for the unstuck argument of 'git clone --config <TAB>', because we have to deal with that '--config=' being part of the current word to be completed. Add an option to the __git_complete_config_variable_name_and_value() and in turn to the __git_complete_config_variable_name() helper functions to specify the current section/variable name to be completed, so they can be used even when completing the stuck argument of '--config='. __git_complete_config_variable_value() already has such an option, and thus no further changes were necessary to complete possible values after 'git clone --config=section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete config variables names and values for 'git clone -c'Libravatar SZEDER Gábor1-0/+6
The previous commits taught the completion script how to complete configuration section, variable names, and their valus after 'git -c <TAB>', and with a bit of foresight encapsulated all that in a dedicated helper function. Use that function to complete the unstuck argument of 'git config -c|--config <TAB>', which expect configuration variables and values in the same 'section.name=value' form. Note that handling the struck argument for 'git clone --config=<TAB>' requires some extra care, so it will be done a separate patch. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete values of configuration variables after 'git -c var='Libravatar SZEDER Gábor1-24/+41
'git config' expects a configuration variable's name and value in separate options, so we complete values as they stand on their own on the command line. 'git -c', however, expects them in a single option joined by a '=' character, so we should be able to complete values when they are following 'section.name=' in the same word. Add new options to the __git_complete_config_variable_value() function to allow callers to specify the current word to be completed and the configuration variable whose value is to be completed, and use these to complete possible values after 'git -c 'section.name=<TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete configuration sections and variable names for 'git -c'Libravatar SZEDER Gábor1-13/+46
'git config' expects a configuration variable's name and value in separate arguments, so we let the __gitcomp() helper append a space character to each variable name by default, like we do for most other things (--options, refs, paths, etc.). 'git -c', however, expects them in a single option joined by a '=' character, i.e. 'section.name=value', so we should append a '=' character to each fully completed variable name, but no space, so the user can continue typing the value right away. Add an option to the __git_complete_config_variable_name() function to allow callers to specify an alternate suffix to add, and use it to append that '=' character to configuration variables. Update the __gitcomp() helper function to not append a trailing space to any completion words ending with a '=', not just to those option with a stuck argument. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: split _git_config()Libravatar SZEDER Gábor1-9/+30
_git_config() contains two enormous case statements, one to complete configuration sections and variable names, and the other to complete their values. Split these out into two separate helper functions, so in the next patches we can use them to implement completion for 'git -c <TAB>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: simplify inner 'case' pattern in __gitcomp()Libravatar SZEDER Gábor1-2/+2
The second '*' in the '--*=*' pattern of the inner 'case' statement of the __gitcomp() helper function never matches anything, so let's use '--*=' instead. The purpose of that inner case statement is to decide when to append a trailing space to the listed options and when not. When an option requires a stuck argument, i.e. '--option=', then the trailing space should not be added, so the user can continue typing the required argument right away. That '--*=*' pattern is supposed to match these options, but for this purpose that second '*' is unnecessary, a '--*=' pattern works just as well. That second '*' would only make a difference in case of a possible completion word like '--option=value', but our completion script never passes such a word to __gitcomp(), because the '--option=' and its 'value' must be completed separately. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: use 'sort -u' to deduplicate config variable namesLibravatar SZEDER Gábor1-1/+1
The completion script runs the classic '| sort | uniq' pipeline to deduplicate the output of 'git help --config-for-completion'. 'sort -u' does the same, but uses one less external process and pipeline stage. Not a bit win, as it's only run once as the list of supported configuration variables is initialized, but at least it sets a better example for others to follow. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: deduplicate configuration sectionsLibravatar SZEDER Gábor1-1/+9
The number of configuration variables listed by the completion script grew quite when we started to auto-generate it from the documentation [1], so we now complete them in two steps: first we list only the section names, then the rest [2]. To get the section names we simply strip everything following the first dot in each variable name, resulting in a lot of repeated section names, because most sections contain more than one configuration variable. This is not a correctness issue in practice, because Bash's completion facilities remove all repetitions anyway, but these repetitions make testing a bit harder. Replace the small 'sed' script removing subsections and variable names with an 'awk' script that does the same, and in addition removes any repeated configuration sections as well (by first creating and filling an associative array indexed by all encountered configuration sections, and then iterating over this array and printing the indices, i.e. the unique section names). This change makes the failing 'git config - section' test in 't9902-completion.sh' pass. Note that this changes the order of section names in the output, and makes it downright undeterministic, but this is not an issue, because Bash sorts them before presenting them to the user, and our completion tests sort them as well before comparing with the expected output. Yeah, it would be simpler and shorter to just append '| sort -u' to that command, but that would incur the overhead of one more external process and pipeline stage every time a user completes configuration sections. [1] e17ca92637 (completion: drop the hard coded list of config vars, 2018-05-26) [2] f22f682695 (completion: complete general config vars in two steps, 2018-05-27) Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: complete more values of more 'color.*' configuration variablesLibravatar SZEDER Gábor1-5/+4
Most 'color.*' configuration variables, with the sole exception of 'color.pager', accept the same set of values, but our completion script recognizes only about half of them. We could explicitly add all those missing variables, but let's try to reduce future maintenance burden, and use the catch-all 'color.*' pattern instead, so this list won't get out of sync when a similar new configuration variable accepting the same values is introduced [1]. Furthermore, their documentation explicitly mentions that they all accept the standard boolean values 'false' and 'true' as well, so list these, too, among the possible values. [1] OTOH, there will be a maintenance burden if ever a new 'color.something' is introduced which doesn't accept the same set of values. We'll see which one happens first... Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-13completion: fix a typo in a commentLibravatar SZEDER Gábor1-1/+1
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-08-02Merge branch 'js/visual-studio'Libravatar Junio C Hamano4-94/+470
Support building Git with Visual Studio The bits about .git/branches/* have been dropped from the series. We may want to drop the support for it, but until that happens, the tests should rely on the existence of the support to pass. * js/visual-studio: (23 commits) git: avoid calling aliased builtins via their dashed form bin-wrappers: append `.exe` to target paths if necessary .gitignore: ignore Visual Studio's temporary/generated files .gitignore: touch up the entries regarding Visual Studio vcxproj: also link-or-copy builtins msvc: add a Makefile target to pre-generate the Visual Studio solution contrib/buildsystems: add a backend for modern Visual Studio versions contrib/buildsystems: handle options starting with a slash contrib/buildsystems: also handle -lexpat contrib/buildsystems: handle libiconv, too contrib/buildsystems: handle the curl library option contrib/buildsystems: error out on unknown option contrib/buildsystems: optionally capture the dry-run in a file contrib/buildsystems: redirect errors of the dry run into a log file contrib/buildsystems: ignore gettext stuff contrib/buildsystems: handle quoted spaces in filenames contrib/buildsystems: fix misleading error message contrib/buildsystems: ignore irrelevant files in Generators/ contrib/buildsystems: ignore invalidcontinue.obj Vcproj.pm: urlencode '<' and '>' when generating VC projects ...
2019-07-29vcxproj: also link-or-copy builtinsLibravatar Johannes Schindelin1-0/+3
The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. Absolutely not what we want. We want to have confidence that our test covers the MSVC-built Git executables, and not some random stuff. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29msvc: add a Makefile target to pre-generate the Visual Studio solutionLibravatar Johannes Schindelin1-1/+2
The entire idea of generating the VS solution makes only sense if we generate it via Continuous Integration; otherwise potential users would still have to download the entire Git for Windows SDK. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of Git for Windows' SDK). So let's just add a target in the Makefile that can be used to generate said solution; The generated files will then be committed so that they can be pushed to a branch ready to check out by Visual Studio users. To make things even more useful, we also generate and commit other files that are required to run the test suite, such as templates and bin-wrappers: with this, developers can run the test suite in a regular Git Bash after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: add a backend for modern Visual Studio versionsLibravatar Johannes Schindelin1-0/+385
Based on the previous patches in this patch series that fixed the generator for `.vcproj` files (which were used by Visual Studio prior to 2015 to define projects), this patch offers to generate project definitions for neweer versions of Visual Studio (which use `.vcxproj` files). To that end, this patch copy-edits the generator of the `.vcproj`. In addition, we now use the `vcpkg` system which allows us to build Git's dependencies (e.g. curl, libexpat) conveniently. The support scripts were introduced in the `jh/msvc` patch series, and with this patch we initialize the `vcpkg` conditionally, in the `libgit` project's `PreBuildEvent`. To allow for parallel building of the projects, we therefore put `libgit` at the bottom of the project hierarchy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle options starting with a slashLibravatar Johannes Schindelin1-1/+1
With the recent changes to allow building with MSVC=1, we now pass the /OPT:REF option to the compiler. This confuses the parser that wants to turn the output of a dry run into project definitions for QMake and Visual Studio: Unhandled link option @ line 213: /OPT:REF at [...] Let's just extend the code that passes through options that start with a dash, so that it passes through options that start with a slash, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: also handle -lexpatLibravatar Johannes Schindelin1-0/+2
This is a dependency required for the non-smart HTTP backend. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle libiconv, tooLibravatar Johannes Schindelin1-0/+2
Git's test suite shows tons of breakages unless Git is compiled *without* NO_ICONV. That means, in turn, that we need to generate build definitions *with* libiconv, which in turn implies that we have to handle the -liconv option properly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle the curl library optionLibravatar Philip Oakley1-1/+3
Upon seeing the '-lcurl' option, point to the libcurl.lib. While there, fix the elsif indentation. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: error out on unknown optionLibravatar Johannes Schindelin1-0/+2
One time too many did this developer call the `generate` script passing a `--make-out=<PATH>` option that was happily ignored (because there should be a space, not an equal sign, between `--make-out` and the path). And one time too many, this script not only ignored it but did not even complain. Let's fix that. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: optionally capture the dry-run in a fileLibravatar Philip Oakley1-0/+10
Add an option for capturing the output of the make dry-run used in determining the msvc-build structure for easy debugging. You can use the output of `--make-out <path>` in subsequent runs via the `--in <path>` option. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: redirect errors of the dry run into a log fileLibravatar Philip Oakley1-1/+6
Rather than swallowing the errors, it is better to have them in a file. To make it obvious what this is about, use the file name 'msvc-build-makedryerrors.txt'. Further, if the output is empty, simply delete that file. As we target Git for Windows' SDK (which, unlike its predecessor msysGit, offers Perl versions newer than 5.8), we can use the quite readable syntax `if -f -z $ErrsFile` (available in Perl >=5.10). Note that the file will contain the new values of the GIT_VERSION and GITGUI_VERSION if they were generated by the make file. They are omitted if the release is tagged and indentically defined in their respective GIT_VERSION_GEN file DEF_VER variables. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: ignore gettext stuffLibravatar Philip Oakley1-0/+6
Git's build contains steps to handle internationalization. This caused hiccups in the parser used to generate QMake/Visual Studio project files. As those steps are irrelevant in this context, let's just ignore them. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle quoted spaces in filenamesLibravatar Philip Oakley1-3/+4
The engine.pl script expects file names not to contain spaces. However, paths with spaces are quite prevalent on Windows. Use shellwords() rather than split() to parse them correctly. Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>