Test 2 19 rc1 #1806
Merged
Test 2 19 rc1 #1806
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
MS Visual C suggests that the construct condition ? (int) i : (ptrdiff_t) d is incorrect. Let's fix this by casting to ptrdiff_t also for the positive arm of the conditional. Signed-off-by: Johannes Schindelin <[email protected]>
The purpose of this function is to stat() the files listed in the index in a multi-threaded fashion. It is called directly after reading the index in the read_index_preloaded() function. However, in some cases we may want to separate the index reading from the preloading step, e.g. in builtin/add.c, where we need to load the index before we parse the pathspecs (which needs to error out if one of the pathspecs refers to a path within a submodule, for which the index must have been read already), and only then will we want to preload, possibly limited by the just-parsed pathspecs. So let's just export that function to allow calling it separately. Signed-off-by: Johannes Schindelin <[email protected]>
We do have a lovely Makefile option to state that that header file is not available. Let's use it everywhere... Signed-off-by: Johannes Schindelin <[email protected]>
Just like with other Git commands, this option makes it read the paths from the standard input. It comes in handy when resetting many, many paths at once and wildcards are not an option (e.g. when the paths are generated by a tool). Note: we first parse the entire list and perform the actual reset action only in a second phase. Not only does this make things simpler, it also helps performance, as do_diff_cache() traverses the index and the (sorted) pathspecs in simultaneously to avoid unnecessary lookups. This feature is marked experimental because it is still under review in the upstream Git project. Signed-off-by: Johannes Schindelin <[email protected]>
When using cvsnt + msys + git, it seems like the output of cvs status had \r\n in it, and caused the command to fail. This fixes that. Signed-off-by: Dustin Spicuzza <[email protected]>
Teach "add" to use preload-index and fscache features to improve performance on very large repositories. During an "add", a call is made to run_diff_files() which calls check_remove() for each index-entry. This calls lstat(). On Windows, the fscache code intercepts the lstat() calls and builds a private cache using the FindFirst/FindNext routines, which are much faster. Somewhat independent of this, is the preload-index code which distributes some of the start-up costs across multiple threads. We need to keep the call to read_cache() before parsing the pathspecs (and hence cannot use the pathspecs to limit any preload) because parse_pathspec() is using the index to determine whether a pathspec is, in fact, in a submodule. If we would not read the index first, parse_pathspec() would not error out on a path that is inside a submodule, and t7400-submodule-basic.sh would fail with not ok 47 - do not add files from a submodule We still want the nice preload performance boost, though, so we simply call read_cache_preload(&pathspecs) after parsing the pathspecs. Signed-off-by: Jeff Hostetler <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
When compiling with Visual Studio, the projects' names are identical to the executables modulo the extensions. Which means that the bin-wrappers *need* to target the .exe files lest they try to execute directories. Signed-off-by: Johannes Schindelin <[email protected]>
Git's source code wants to be able to close() the same file descriptor multiple times, ignoring the error returned by the second call (and the ones after that), or to access the osfhandle of an already-closed stdout, among other things that the UCRT does not like. Simply linking invalidcontinue.obj allows such usage without resorting to Debug Assertions (or exiting with exit code 9 in Release Mode). Let's add a note so we don't forget, as suggested by Jeff Hostetler. See https://msdn.microsoft.com/en-us/library/ms235330.aspx for more details. Signed-off-by: Johannes Schindelin <[email protected]>
This is one of the few places where Git violates its own deprecation of the dashed form. It is not necessary, either. As of 595d59e (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. Signed-off-by: Johannes Schindelin <[email protected]>
It is a real old anachronism from the Cogito days to have a .git/branches/ directory. And to have tests that ensure that Cogito users can migrate away from using that directory. But so be it, let's continue testing it. Let's make sure, however, that git init does not need to create that directory. This bug was noticed when testing with templates that had been pre-committed, skipping the empty branches/ directory of course because Git does not track empty directories. Signed-off-by: Johannes Schindelin <[email protected]>
Add the Microsoft .manifest pattern, and correct the generic 'Debug' and 'Release' directory patterns which were mechanically adjusted way back in c591d5f (gitignore: root most patterns at the top-level directory, 2009-10-26) to allow multi-level projects within the Git suite. Signed-off-by: Philip Oakley <[email protected]>
…stem Signed-off-by: Philip Oakley <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
The error message talked about a "lib option", but it clearly referred to a link option. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Upon seeing the '-lcurl' option, point to the libcurl.lib. While there, fix the elsif indentation. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
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 <[email protected]>
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 <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
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 <[email protected]>
The .sln/.vcproj files were used to define projects up until Visual Studio 2008, but starting with Visual Studio 2010 the project definitions are stored in .sln/.vcxproj files (which can also be used by the MSBuild system). Let's just copy-edit the generator of the .vcproj files to a new generator that produces .vcxproj files directly, without forcing Visual Studio to upgrade the project definitions. Signed-off-by: Johannes Schindelin <[email protected]>
…udio Visual Studio has this very neat feature that you can get dependencies in the form of NuGet packages, and even further: you can specify in a project what NuGet packages it needs. These dependencies can then be fetched via right-clicking the solution in the Solution Explorer and clicking the "Restore NuGet Packages" entry. This feature is so neat, in fact, that we want to support it in Git for Windows. The idea is that we will be able to provide developers with a checkout of the Git sources that can be built outside of the Git for Windows SDK, using *only* Visual Studio. Signed-off-by: Johannes Schindelin <[email protected]>
Delete the duplicated GUID from the generation code for the Visual Studio .sln project file. The duplicate GUID tended to be allocated to test-svn-fe, which was then ignored by Visual Studio / MSVC, and its omission from the build never noticed. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Visual Studio takes the first listed application/library as the default startup project [1]. Detect the 'git' project and place it the head of the apps list, rather than 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 <[email protected]>
Needed for: test-config; t-dump-split-index; t-dump-untracked-cache; t-fake-ssh; t-sha1-array; t-submodule-config. Plus a few spares. Signed-off-by: Philip Oakley <[email protected]>
It is not necessary, and Visual Studio 2015 no longer supports it, anyway. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
Microsoft flipped the Windows Safe Exception Handling default in VS2013 so that zlib became unacceptable to certain OS versions (Vista and subsequent 32-bit OS's) without the addition of the option -SAFESEH:NO. Provide a switch to disable the Safe Exception Handler when required. The option ImageHasSafeExceptionHandlers for VS2013 is not available in earlier versions, so use the SAFESEH:NO linker flag. See https://msdn.microsoft.com/en-us/library/9a89h429.aspx for further details. This has only had limited testing due to the lack of a suitable system. Helped-by: Yue Lin Ho <[email protected]> Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
This is part two of the Ctrl+C story, where part one is git-for-windows/MSYS2-packages@f4fda0f30aa. Part one took care of extending the signal handling in the MSYS2 runtime such that non-MSYS2 processes "receive" a SIGINT by injecting a remote thread that runs kernel32!CtrlRoutine as if GenerateConsoleCtrlHandler() had been called (but in contrast to the latter, only one process is targeted at a time, not every process attached to the same Console) into the process that needs to be interrupted as well as into all of the spawned child processes. Part two now takes care of removing the misguided "kill all spawned children" atexit() handler, and it also installs a ConsoleCtrl handler to run Git's SIGINT handlers, such as the one waiting for the pager to exit. Signed-off-by: Johannes Schindelin <[email protected]>
Add new condition to invoke vcpkg_install.bat: it's not enough to check the presence of folder vcpkg. We need to check the presence of some header files because this is one of the main goals of this script. Previous build attempt could be aborted, so the folder will exist but the project will not be built properly. Signed-off-by: Olga Telezhnaia <[email protected]>
Support windows container.
vcxproj: change build logic
Completely convert the pathname expoted in the %msvc_bin_dir_msys%
variable to MSYS format with forward slashes rather than a mixture
of forward and back slashes.
This solves an obscure problem observed by some developers:
[...]
http-push.c
CC remote-curl.o
remote-curl.c
* new script parameters
GEN git-instaweb
sed: -e expression git-for-windows#7, char 155: invalid reference \2 on `s' command's RHS
make: *** [Makefile:2023: git-instaweb] Error 1
Signed-off-by: Jeff Hostetler <[email protected]>
This commit adds an extra example to submit an incrementing version patch series to the mailing list which should be the continuation to previous patch series. This closes git-for-windows#1745 Signed-off-by: Pratik Karki <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
…in-dir find_vs_env.bat: Fix bin dir path used by msys
This merges the builtin stash. Upstream Git did not integrate it into any stable integration branch yet, but the performance improvements are substantial enough, especially on Windows, that we really, really, really want to have it early. Signed-off-by: Johannes Schindelin <[email protected]>
This is the first batch of the patches that turn `git rebase` into a builtin. This not only helps performance on Windows, but *especially* makes things more robust, as no MSYS2 Bash will be required to run this command any longer. Signed-off-by: Johannes Schindelin <[email protected]>
This is the second wave of patches to bring us closer to a builtin `git rebase`. Signed-off-by: Johannes Schindelin <[email protected]>
This set of patches implements the actions (such as --continue, --skip, etc) in the builtin rebase. Signed-off-by: Johannes Schindelin <[email protected]>
This wave of built rebase patches implements the remaining rebase options in the builtin rebase. Signed-off-by: Johannes Schindelin <[email protected]>
This simply copies the version as of v2.19.0-rc0 verbatim. As of now, it is not hooked up (because it needs a couple more changes to work); The next commit will use the scripted interactive rebase backend from `git rebase` again when `rebase.useBuiltin=false`. Signed-off-by: Johannes Schindelin <[email protected]>
This fifth batch of builtin rebase patches concludes the conversion: the builtin rebase is now feature-complete. Signed-off-by: Johannes Schindelin <[email protected]>
We recently converted both the `git rebase` and the `git rebase -i` command from Unix shell scripts to builtins. The former has a safety valve allowing to fall back to the scripted `rebase`, just in case that there is a bug in the builtin `rebase`: setting the config variable `rebase.useBuiltin` to `false` will fall back to using the scripted version. The latter did not have such a safety hatch. Let's reinstate the scripted interactive rebase backend so that `rebase.useBuiltin=false` will not use the builtin interactive rebase, just in case that an end user runs into a bug with the builtin version and needs to get out of the fix really quickly. This is necessary because Git for Windows wants to ship the builtin rebase/interactive rebase earlier than core Git: Git for Windows v2.19.0 will come with the option of a drastically faster (if a lot less battle-tested) `git rebase`/`git rebase -i`. As the file name `git-rebase--interactive` is already in use, let's rename the scripted backend to `git-legacy-rebase--interactive`. A couple of additional touch-ups are needed (such as teaching the builtin `rebase--interactive`, which assumed the role of the `rebase--helper`, to perform the two tricks to skip the unnecessary picks and to generate a new todo list) to make things work again. Signed-off-by: Johannes Schindelin <[email protected]>
This branch first merges the builtin interactive rebase, and then teaches the builtin rebase to hand off interactive rebases to the builtin backend correctly. Signed-off-by: Johannes Schindelin <[email protected]>
This simply copies the version as of v2.19.0-rc0 verbatim. As of now, it is not hooked up. The next commit will change the builtin `stash` to hand off to the scripted `git stash` when `stash.useBuiltin=false`. Signed-off-by: Johannes Schindelin <[email protected]>
This final patch flips the switch and makes the builtin rebase the default. The old, Unix shell scripted version can still be called via git -c rebase.useBuiltin=false rebase [...] Signed-off-by: Johannes Schindelin <[email protected]>
We recently converted the `git stash` command from Unix shell scripts to builtins. Just like we have `rebase.useBuiltin` to fall back to the scripted rebase, to give end users a way out when they discover a bug in the builtin command, this commit adds support for `stash.useBuiltin`. This is necessary because Git for Windows wants to ship the builtin stash earlier than core Git: Git for Windows v2.19.0 will come with the option of a drastically faster (if a lot less battle-tested) `git stash`. As the file name `git-stash` is already in use, let's rename the scripted backend to `git-legacy-stash`. To make the test suite pass with `stash.useBuiltin=false`, this commit also backports rudimentary support for `-q` (but only *just* enough to appease the test suite), and adds a super-ugly hack to force exit code 129 for `git stash -h`. Signed-off-by: Johannes Schindelin <[email protected]>
This *would* be a fixup commit, except that we want to avoid rewriting commits that we merged from upstream's `pu` branch. Instead, we want to send a new iteration, and then re-merge the new iteration once it made it into the `pu` branch. Signed-off-by: Johannes Schindelin <[email protected]>
This patch teaches the builtin rebase to avoid the scripted --am backend and call `git format-patch` and `git am` directly. Meaning: apart from the --merge and the --preserve-merges backends, `git rebase` is now implemented in pure C, with no need to ask the Unix shell interpreter for help. This brings us really close to a fully builtin `git rebase`: the --preserve-merges mode is about to be deprecated (as soon as the --rebase-merges mode has proven stable and robust enough), and there are plans to scrap the `git-rebase--merge` backend in favor of teaching the interactive rebase enough tricks to run the --merge mode, too. Signed-off-by: Johannes Schindelin <[email protected]>
The upcoming Git for Windows v2.19.0 wants to ship with the builtin versions of stash, rebase and rebase -i. The reason: these are just *so much faster*: t3400 and t3404 run about 60-70 percent faster, and t3903 even more than 80% faster. However, these are still all pretty fresh, still being reviewed and iterated on the Git mailing list. So let's try to give users a way to test these (or to boldly use them for their mission-critical tasks, as this here developer plans on doing), but stay with the safe option by default: use the scripted versions (which might be slow, but they are well tested). Signed-off-by: Johannes Schindelin <[email protected]>
A couple of fixes that should be squashed during the next merging rebase of Git for Windows. Signed-off-by: Johannes Schindelin <[email protected]>
This branch adds back the scripted versions, then adds the option to use the builtin versions of `stash` and `rebase` by setting `stash.useBuiltin=true` and `rebase.useBuiltin=true`, respectively, (the latter already worked for the top-level `git rebase` command and the `--am` backend, and now it also works for the interactive backend). Signed-off-by: Johannes Schindelin <[email protected]>
dscho
approved these changes
Aug 28, 2018
|
Oh, and once the pre-release has been published, I think we should push this to |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Test update of Git for Windows