summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2019-10-06vcxproj: only copy `git-remote-http.exe` once it was builtLibravatar Johannes Schindelin2-3/+10
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-10-06msvc: work around a bug in GetEnvironmentVariable()Libravatar Johannes Schindelin1-0/+2
The return value of that function is 0 both for variables that are unset, as well as for variables whose values are empty. To discern those two cases, one has to call `GetLastError()`, whose return value is `ERROR_ENVVAR_NOT_FOUND` and `ERROR_SUCCESS`, respectively. Except that it is not actually set to `ERROR_SUCCESS` in the latter case, apparently, but the last error value seems to be simply unchanged. To work around this, let's just re-set the last error value just before inspecting the environment variable. This fixes a problem that triggers failures in t3301-notes.sh (where we try to override config settings by passing empty values for certain environment variables). This problem is hidden in the MINGW build by the fact that older MSVC runtimes (such as the one used by MINGW builds) have a `calloc()` that re-sets the last error value in case of success, while newer runtimes set the error value only if `NULL` is returned by that function. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06msvc: handle DEVELOPER=1Libravatar Johannes Schindelin1-0/+46
We frequently build Git using the `DEVELOPER=1` make setting as a shortcut to enable all kinds of more stringent compiler warnings. Those compiler warnings are relatively specific to GCC, though, so let's try our best to translate them to the equivalent options to pass to MS Visual C++'s `cl.exe`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06msvc: ignore some libraries when linkingLibravatar Johannes Schindelin1-1/+1
To build with MSVC, we "translate" GCC options to MSVC options, and part of those options refer to the libraries to link into the final executable. Currently, this part looks somewhat like this on Windows: -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lssl -lcrypto -lgdi32 -lcrypt32 -lwldap32 -lz -lws2_32 -lexpat Some of those are direct dependencies (such as curl and ssl) and others are indirect (nghttp2 and idn2, for example, are dependencies of curl, but need to be linked in for reasons). We already handle the direct dependencies, e.g. `-liconv` is already handled as adding `libiconv.lib` to the list of libraries to link against. Let's just ignore the remaining `-l*` options so that MSVC does not have to warn us that it ignored e.g. the `/lnghttp2` option. We do that by extending the clause that already "eats" the `-R*` options to also eat the `-l*` options. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06compat/win32/path-utils.h: add #include guardsLibravatar Johannes Schindelin1-0/+5
This adds the common guards that allow headers to be #include'd multiple times. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06winansi: use FLEX_ARRAY to avoid compiler warningLibravatar Johannes Schindelin1-1/+1
MSVC would complain thusly: C4200: nonstandard extension used: zero-sized array in struct/union Let's just use the `FLEX_ARRAY` constant that we introduced for exactly this type of scenario. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-06msvc: avoid using minus operator on unsigned typesLibravatar Johannes Schindelin3-4/+17
MSVC complains about this with `-Wall`, which can be taken as a sign that this is indeed a real bug. The symptom is: C4146: unary minus operator applied to unsigned type, result still unsigned Let's avoid this warning in the minimal way, e.g. writing `-1 - <unsigned value>` instead of `-<unsigned value> - 1`. Note that the change in the `estimate_cache_size()` function is needed because MSVC considers the "return type" of the `sizeof()` operator to be `size_t`, i.e. unsigned, and therefore it cannot be negated using the unary minus operator. Even worse, that arithmetic is doing extra work, in vain. We want to calculate the entry extra cache size as the difference between the size of the `cache_entry` structure minus the size of the `ondisk_cache_entry` structure, padded to the appropriate alignment boundary. To that end, we start by assigning that difference to the `per_entry` variable, and then abuse the `len` parameter of the `align_padding_size()` macro to take the negative size of the ondisk entry size. Essentially, we try to avoid passing the already calculated difference to that macro by passing the operands of that difference instead, when the macro expects operands of an addition: #define align_padding_size(size, len) \ ((size + (len) + 8) & ~7) - (size + len) Currently, we pass A and -B to that macro instead of passing A - B and 0, where A - B is already stored in the `per_entry` variable, ready to be used. This is neither necessary, nor intuitive. Let's fix this, and have code that is both easier to read and that also does not trigger MSVC's warning. While at it, we take care of reporting overflows (which are unlikely, but hey, defensive programming is good!). We _also_ take pains of casting the unsigned value to signed: otherwise, the signed operand (i.e. the `-1`) would be cast to unsigned before doing the arithmetic. Helped-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-10-04push: do not pretend to return `int` from `die_push_simple()`Libravatar Johannes Schindelin1-2/+2
This function is marked as `NORETURN`, and it indeed does not want to return anything. So let's not declare it with the return type `int`. This fixes the following warning when building with MSVC: C4646: function declared with 'noreturn' has non-void return type Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05.gitignore: stop ignoring `.manifest` filesLibravatar Johannes Schindelin1-1/+0
On Windows, it is possible to embed additional metadata into an executable by linking in a "manifest", i.e. an XML document that describes capabilities and requirements (such as minimum or maximum Windows version). These XML documents are expected to be stored in `.manifest` files. At least _some_ Visual Studio versions auto-generate `.manifest` files when none is specified explicitly, therefore we used to ask Git to ignore them. However, we do have a beautiful `.manifest` file now: `compat/win32/git.manifest`, so neither does Visual Studio auto-generate a manifest for us, nor do we want Git to ignore the `.manifest` files anymore. Further reading on auto-generated `.manifest` files: https://docs.microsoft.com/en-us/cpp/build/manifest-generation-in-visual-studio Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29git: avoid calling aliased builtins via their dashed formLibravatar Johannes Schindelin1-3/+0
This is one of the few places where Git violates its own deprecation of the dashed form. It is not necessary, either. As of 595d59e2b53 (git.c: ignore pager.* when launching builtin as dashed external, 2017-08-02), Git wants to ignore the pager.* config setting when expanding aliases. So let's strip out the check_pager_config(<command-name>) call from the copy-edited code. This code actually made it into upstream git.git already, but it was disabled in `#if 0 ... #endif` guards so far. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29bin-wrappers: append `.exe` to target paths if necessaryLibravatar Johannes Schindelin1-1/+1
When compiling with Visual Studio, the projects' names are identical to the executables modulo the extensions. Read: there will exist both a directory called `git` as well as an executable called `git.exe` in the end. Which means that the bin-wrappers *need* to target the `.exe` files lest they try to execute directories. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29.gitignore: ignore Visual Studio's temporary/generated filesLibravatar Johannes Schindelin1-0/+3
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29.gitignore: touch up the entries regarding Visual StudioLibravatar Philip Oakley1-2/+3
Add the Microsoft .manifest pattern, and do not anchor the 'Debug' and 'Release' entries at the top-level directory, to allow for multiple projects (one per target). 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-29vcxproj: also link-or-copy builtinsLibravatar Johannes Schindelin2-0/+18
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 Schindelin3-1/+86
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>
2019-07-29contrib/buildsystems: fix misleading error messageLibravatar Philip Oakley1-1/+1
The error message talked about a "lib option", but it clearly referred to a link 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: ignore irrelevant files in Generators/Libravatar Johannes Schindelin1-1/+1
The Generators/ directory can contain spurious files such as editors' backup files. Even worse, there could be .swp files which are not even valid Perl scripts. Let's just ignore anything but .pm files in said directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: ignore invalidcontinue.objLibravatar Philip Oakley1-3/+7
Since 4b623d8 (MSVC: link in invalidcontinue.obj for better POSIX compatibility, 2014-03-29), invalidcontinue.obj is linked in the MSVC build, but it was not parsed correctly by the buildsystem. Ignore it, as it is known to Visual Studio and will be handled elsewhere. Also only substitute filenames ending with .o when generating the source .c filename, otherwise we would start to expect .cbj files to generate .obj files (which are not generated by our build)... In the future there may be source files that produce .obj files so keep the two issues (.obj files with & without source files) separate. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Duncan Smart <duncan.smart@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: urlencode '<' and '>' when generating VC projectsLibravatar Johannes Schindelin1-0/+8
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: do not configure VCWebServiceProxyGeneratorToolLibravatar Johannes Schindelin1-12/+0
It is not necessary, and Visual Studio 2015 no longer supports it, anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: list git.exe first to be startup projectLibravatar Philip Oakley1-14/+19
Visual Studio takes the first listed application/library as the default startup project [1]. Detect the 'git' project and place it at the head of the project list, rather than at the tail. Export the apps list before libs list for both the projects and global structures of the .sln file. [1] http://stackoverflow.com/questions/1238553/ vs2008-where-is-the-startup-project-setting-stored-for-a-solution "In the solution file, there are a list of pseudo-XML "Project" entries. It turns out that whatever is the first one ends up as the Startup Project, unless it’s overridden in the suo file. Argh. I just rearranged the order in the file and it’s good." "just moving the pseudo-xml isn't enough. You also have to move the group of entries in the "GlobalSection(ProjectConfigurationPlatforms) = postSolution" group that has the GUID of the project you moved to the top. So there are two places to move lines." 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-29Vcproj.pm: auto-generate GUIDsLibravatar Johannes Schindelin1-57/+9
We ran out GUIDs. Again. But there is no need to: we can generate them semi-randomly from the target file name of the project. Note: the Vcproj generator is probably only interesting for historical reasons; nevertheless, the upcoming Vcxproj generator (to support modern Visual Studio versions) is based on the Vcproj generator and it is better to fix this here first. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11The fifth batchLibravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-11Merge branch 'js/mingw-use-utf8'Libravatar Junio C Hamano3-8/+16
Windows update. * js/mingw-use-utf8: mingw: fix possible buffer overrun when calling `GetUserNameW()` mingw: use Unicode functions explicitly mingw: get pw_name in UTF-8 format
2019-07-11Merge branch 'sg/ci-brew-gcc-workaround'Libravatar Junio C Hamano2-3/+5
Dev support update. * sg/ci-brew-gcc-workaround: ci/lib.sh: update a comment about installed P4 and Git-LFS versions ci: disable Homebrew's auto cleanup ci: don't update Homebrew
2019-07-11Merge branch 'kb/windows-force-utf8'Libravatar Junio C Hamano1-1/+19
Windows update. * kb/windows-force-utf8: gettext: always use UTF-8 on native Windows
2019-07-11Merge branch 'dr/progress-i18n'Libravatar Junio C Hamano3-7/+44
Progress messages have been made localizable. * dr/progress-i18n: l10n: localizable upload progress messages
2019-07-11Merge branch 'qn/clone-doc-use-long-form'Libravatar Junio C Hamano1-17/+17
The "git clone" documentation refers to command line options in its description in the short form; they have been replaced with long forms to make them more recognisable. * qn/clone-doc-use-long-form: docs: git-clone: list short form of options first docs: git-clone: refer to long form of options
2019-07-11Merge branch 'js/rebase-reschedule-applies-only-to-interactive'Libravatar Junio C Hamano2-3/+15
The configuration variable rebase.rescheduleFailedExec should be effective only while running an interactive rebase and should not affect anything when running an non-interactive one, which was not the case. This has been corrected. * js/rebase-reschedule-applies-only-to-interactive: rebase --am: ignore rebase.rescheduleFailedExec
2019-07-11Merge branch 'sg/git-C-empty-doc'Libravatar Junio C Hamano1-1/+2
Doc update. * sg/git-C-empty-doc: Document that 'git -C ""' works and doesn't change directory
2019-07-11Merge branch 'jt/t5551-test-chunked'Libravatar Junio C Hamano1-3/+2
Update smart-http test. * jt/t5551-test-chunked: t5551: test usage of chunked encoding explicitly
2019-07-11Merge branch 'js/mingw-gcc-stack-protect'Libravatar Junio C Hamano1-1/+2
Windows update. * js/mingw-gcc-stack-protect: mingw: enable stack smashing protector
2019-07-11Merge branch 'cb/windows-manifest'Libravatar Junio C Hamano2-0/+27
Windows update. * cb/windows-manifest: mingw: embed a manifest to trick UAC into Doing The Right Thing
2019-07-09The fourth batchLibravatar Junio C Hamano1-0/+115
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'ds/fetch-disable-force-notice'Libravatar Junio C Hamano8-1/+88
"git fetch" and "git pull" reports when a fetch results in non-fast-forward updates to let the user notice unusual situation. The commands learned "--no-shown-forced-updates" option to disable this safety feature. * ds/fetch-disable-force-notice: pull: add --[no-]show-forced-updates passthrough fetch: warn about forced updates in branch listing fetch: add --[no-]show-forced-updates argument
2019-07-09Merge branch 'jh/status-aheadbehind'Libravatar Junio C Hamano8-1/+88
"git status" can be told a non-standard default value for the "--[no-]ahead-behind" option with a new configuration variable status.aheadBehind. * jh/status-aheadbehind: status: ignore status.aheadbehind in porcelain formats status: warn when a/b calculation takes too long status: add status.aheadbehind setting
2019-07-09Merge branch 'sg/t5551-fetch-smart-error-is-translated'Libravatar Junio C Hamano1-2/+2
Test update. * sg/t5551-fetch-smart-error-is-translated: t5551: use 'test_i18ngrep' to check translated output
2019-07-09Merge branch 'ms/submodule-foreach-fix'Libravatar Junio C Hamano2-0/+8
"git submodule foreach" did not protect command line options passed to the command to be run in each submodule correctly, when the "--recursive" option was in use. * ms/submodule-foreach-fix: submodule foreach: fix recursion of options
2019-07-09Merge branch 'jh/msvc'Libravatar Junio C Hamano19-62/+620
Support to build with MSVC has been updated. * jh/msvc: msvc: ignore .dll and incremental compile output msvc: avoid debug assertion windows in Debug Mode msvc: do not pretend to support all signals msvc: add pragmas for common warnings msvc: add a compile-time flag to allow detailed heap debugging msvc: support building Git using MS Visual C++ msvc: update Makefile to allow for spaces in the compiler path msvc: fix detect_msys_tty() msvc: define ftello() msvc: do not re-declare the timespec struct msvc: mark a variable as non-const msvc: define O_ACCMODE msvc: include sigset_t definition msvc: fix dependencies of compat/msvc.c mingw: replace mingw_startup() hack obstack: fix compiler warning cache-tree/blame: avoid reusing the DEBUG constant t0001 (mingw): do not expect a specific order of stdout/stderr Mark .bat files as requiring CR/LF endings mingw: fix a typo in the msysGit-specific section
2019-07-09Merge branch 'sg/rebase-progress'Libravatar Junio C Hamano8-98/+104
Use "Erase in Line" CSI sequence that is already used in the editor support to clear cruft in the progress output. * sg/rebase-progress: progress: use term_clear_line() rebase: fix garbled progress display with '-x' pager: add a helper function to clear the last line in the terminal t3404: make the 'rebase.missingCommitsCheck=ignore' test more focused t3404: modernize here doc style