[DO NOT MERGE YET] Rebase to v2.20.0-rc0 #1939
Closed
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
Without an error message when stat() failed, e.g. `git clean` would abort without an error message, leaving the user quite puzzled. This fixes git-for-windows#521 Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
In particular on Windows, where the default maximum path length is quite small, but there are ways to circumvent that limit in many cases, it is very important that users be given an indication why their command failed because of too long paths when it did. This test case makes sure that a warning is issued that would have helped the user who reported Git for Windows' issue 521: git-for-windows#521 Signed-off-by: Johannes Schindelin <[email protected]>
When a third-party tool periodically runs `git status` in order to keep track of the state of the working tree, it is a bad idea to lock the index: it might interfere with interactive commands executed by the user, e.g. when the user wants to commit files. Git for Windows introduced the `--no-lock-index` option a long time ago to fix that (it made it into Git for Windows v2.9.2(3)) by simply avoiding to write that file. The downside is that the periodic `git status` calls will be a little bit more wasteful because they may have to refresh the index repeatedly, only to throw away the updates when it exits. This cannot really be helped, though, as tools wanting to get a periodic update of the status have no way to predict when the user may want to lock the index herself. Sadly, a competing approach was submitted (by somebody who apparently has less work on their plate than this maintainer) that made it into v2.15.0 but is *different*: instead of a `git status`-only option, it is an option that comes *before* the Git command and is called differently, too. Let's give previous users a chance to upgrade to newer Git for Windows versions by handling the `--no-lock-index` option, still, though with a big fat warning. Signed-off-by: Johannes Schindelin <[email protected]>
It was a bad idea to just remove that option from Git for Windows v2.15.0, as early users of that (still experimental) option would have been puzzled what they are supposed to do now. So let's reintroduce the flag, but make sure to show the user good advice how to fix this going forward. We'll remove this option in a more orderly fashion either in v2.16.0 or in v2.17.0. Signed-off-by: Johannes Schindelin <[email protected]>
The option is deprecated now, and we better make sure that keeps saying so until we finally remove it. Suggested by Kevin Willford. Signed-off-by: Johannes Schindelin <[email protected]>
…sses When spawning child processes, we really should be careful which file handles we let them inherit. This is doubly important on Windows, where we cannot rename, delete, or modify files if there is still a file handle open. Sadly, we have to guard this test inside #ifdef WIN32: we need to use the value of the HANDLE directly, and that concept does not exist on Linux/Unix. Signed-off-by: Johannes Schindelin <[email protected]>
For some reason, when being called via TortoiseGit the standard handles, or at least what is returned by _get_osfhandle(0) for standard input, can take on the value (HANDLE)-2 (which is not a legal value, according to the documentation). Even if this value is not documented anywhere, CreateProcess() seems to work fine without complaints if hStdInput set to this value. In contrast, the upcoming code to restrict which file handles get inherited by spawned processes would result in `ERROR_INVALID_PARAMETER` when including such handle values in the list. To help this, special-case the value (HANDLE)-2 returned by _get_osfhandle() and replace it with INVALID_HANDLE_VALUE, which will hopefully let the handle inheritance restriction work even when called from TortoiseGit. This fixes git-for-windows#1481 Signed-off-by: Johannes Schindelin <[email protected]>
It is better to state clearly expectations and intentions than to assume quietly that everybody agrees. This Code of Conduct is the Open Code of Conduct as per http://todogroup.org/opencodeofconduct/ (the only modifications are the adjustments to reflect that there is no "response team" in addition to the Git for Windows maintainer, and the addition of the link to the Open Code of Conduct itself). [Completely revamped, based on the Covenant 1.4 by Brendan Forster] Signed-off-by: Johannes Schindelin <[email protected]>
Getting started contributing to Git can be difficult on a Windows machine. CONTRIBUTING.md contains a guide to getting started, including detailed steps for setting up build tools, running tests, and submitting patches to upstream. [includes an example by Pratik Karki how to submit v2, v3, v4, etc.] Signed-off-by: Derrick Stolee <[email protected]>
Includes touch-ups by Philip Oakley. Signed-off-by: Johannes Schindelin <[email protected]>
With improvements by Clive Chan, Adric Norris, Ben Bodenmiller and Philip Oakley. Helped-by: Clive Chan <[email protected]> Helped-by: Adric Norris <[email protected]> Helped-by: Ben Bodenmiller <[email protected]> Helped-by: Philip Oakley <[email protected]> Signed-off-by: Brendan Forster <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
Git for Windows accepts pull requests; Core Git does not. Therefore we need to adjust the template (because it only matches core Git's project management style, not ours). Also: direct Git for Windows enhancements to their contributions page, space out the text for easy reading, and clarify that the mailing list is plain text, not HTML. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
The sentiment bot will help detect when things get too heated. Hopefully. Signed-off-by: Johannes Schindelin <[email protected]>
Compared to `get_oid()`, `get_oidf()` has as parameters a pointer to `object_id`, a printf format string and additional arguments. This will help simplify the code in subsequent commits. Original-idea-by: Johannes Schindelin <[email protected]> Signed-off-by: Paul-Sebastian Ungureanu <[email protected]>
Git documentation refers to $HOME and $XDG_CONFIG_HOME often, but does not specify how or where these values come from on Windows where neither is set by default. The new documentation reflects the behavior of setup_windows_environment() in compat/mingw.c. Signed-off-by: Alejandro Barreto <[email protected]>
Implement `strbuf_join_argv()` to join arguments into a strbuf. Signed-off-by: Paul-Sebastian Ungureanu <[email protected]>
In preparation for converting the stash command incrementally to a builtin command, this patch improves test coverage of the option parsing. Both for having too many parameters, or too few. Signed-off-by: Joel Teichroeb <[email protected]> Signed-off-by: Paul-Sebastian Ungureanu <[email protected]>
On a case-insensitive filesystem, such as HFS+ or NTFS, it is possible that the idea Bash has of the current directory differs in case from what Git thinks it is. That's totally okay, though, and we should not expect otherwise. Reported by Jameson Miller. Signed-off-by: Johannes Schindelin <[email protected]>
This patch series contains a couple of fixes revolving around testing an installed Git, via GIT_TEST_INSTALLED=/path/to/git. The original motivation for these patches is that Git for Windows wants to provide a version where the Unix shell scripts are interpreted by BusyBox (to reduce the footprint on disk, mainly), and we want to verify that this actually works, and is not perchance missing any Unix shell tool that is present in the Git for Windows SDK but is missing from the installed set of files. While the BusyBox-based Git for Windows is not ready for prime time, this here patch series is, and might be useful for packagers who want to verify a similar scenario. Signed-off-by: Johannes Schindelin <[email protected]>
When compiling Git with a runtime prefix (so that it can be installed into any location, finding its libexec/ directory relative to the location of the `git` executable), it is convenient to provide "absolute" Unix-y paths e.g. for http.sslCAInfo, and have those absolute paths be resolved relative to the runtime prefix. This patch makes it so for Windows. It is up for discussion whether we want this for other platforms, too, as long as building with RUNTIME_PREFIX. Signed-off-by: Johannes Schindelin <[email protected]>
Signed-off-by: Johannes Schindelin <[email protected]>
When redirecting stdout/stderr to the same file, we cannot guarantee that stdout will come first. In fact, in this test case, it seems that an MSVC build always prints stderr first. In any case, this test case does not want to verify the *order* but the *presence* of both outputs, so let's relax the test a little. Signed-off-by: Johannes Schindelin <[email protected]>
In MSVC, the DEBUG constant is set automatically whenever compiling with debug information. This is clearly not what was intended in cache-tree.c, so let's use a less ambiguous constant there. Signed-off-by: Jeff Hostetler <[email protected]>
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]>
Git for Windows has special code to retrieve the command-line parameters (and even the environment) in UTF-16 encoding, so that they can be converted to UTF-8. This is necessary because Git for Windows wants to use UTF-8 encoded strings throughout its code, and the main() function does not get the parameters in that encoding. To do that, we used the __wgetmainargs() function, which is not even a Win32 API function, but provided by the MINGW "runtime" instead. Obviously, this method would not work with any other compiler than GCC, and in preparation for compiling with Visual C++, we would like to avoid that. Lucky us, there is a much more elegant way: we simply implement wmain() and link with -municode. The command-line parameters are passed to wmain() encoded in UTF-16, as desired, and this method also works with Visual C++. Signed-off-by: Johannes Schindelin <[email protected]>
The file compat/msvc.c includes compat/mingw.c, which means that we have to recompile compat/msvc.o if compat/mingw.c changes. Signed-off-by: Johannes Schindelin <[email protected]>
On MSVC (VS2008) sigset_t is not defined. Signed-off-by: Philip Oakley <[email protected]>
This constant is not defined in MSVC's headers. In UCRT's fcntl.h, _O_RDONLY, _O_WRONLY and _O_RDWR are defined as 0, 1 and 2, respectively. Yes, that means that UCRT breaks with the tradition that O_RDWR == O_RDONLY | O_WRONLY. It is a perfectly legal way to define those constants, though, therefore we need to take care of defining O_ACCMODE accordingly. This is particularly important in order to keep our "open() can set errno to EISDIR" emulation working: it tests that (flags & O_ACCMODE) is not identical to O_RDONLY before going on to test specifically whether the file for which open() reported EACCES is, in fact, a directory. Signed-off-by: Philip Oakley <[email protected]> Signed-off-by: Johannes Schindelin <[email protected]>
VS2015 complains when using a const pointer in memcpy()/free(). Signed-off-by: Jeff Hostetler <[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]>
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]>
To avoid having to play tricks as in earlier rounds, we bit the sour apple and rebased the `builtin-stash-rebase-v3` branch thicket onto the commit starting Git for Windows' merging-rebase. (The merging-rebase pulls in the previous branch thicket via a "fake merge", i.e. a merge commit that does not actually apply any changes from the merged commit history. This has the unfortunate side effect of confusing `merge` into thinking that any branch that was merged into an earlier round does not need to be merged again.) Signed-off-by: Johannes Schindelin <[email protected]>
Use FindFirstFileExW with FindExInfoBasic to avoid forcing NTFS to look up the short name. Also switch to a larger (64K vs 4K) buffer using FIND_FIRST_EX_LARGE_FETCH to minimize round trips to the kernel. In a repo with ~200K files, this drops warm cache status times from 3.19 seconds to 2.67 seconds for a 16% savings. Signed-off-by: Ben Peart <[email protected]>
Fix t0001 when the current working directory differs in case from the canonical form
At the end of the status command, disable and free the fscache so that we don't leak the memory and so that we can dump the fscache statistics. Signed-off-by: Ben Peart <[email protected]>
Add support to fscache to enable running the entire test suite with the fscache enabled. Signed-off-by: Ben Peart <[email protected]>
Add tracing around initializing and discarding mempools. In discard report on the amount of memory unused in the current block to help tune setting the initial_size. Signed-off-by: Ben Peart <[email protected]>
Update enable_fscache() to take an optional initial size parameter which is used to initialize the hashmap so that it can avoid having to rehash as additional entries are added. Add a separate disable_fscache() macro to make the code clearer and easier to read. Signed-off-by: Ben Peart <[email protected]>
The threading model for fscache has been to have a single, global cache. This puts requirements on it to be thread safe so that callers like preload-index can call it from multiple threads. This was implemented with a single mutex and completion events which introduces contention between the calling threads. Simplify the threading model by making fscache thread specific. This allows us to remove the global mutex and synchronization events entirely and instead associate a fscache with every thread that requests one. This works well with the current multi-threading which divides the cache entries into blocks with a separate thread processing each block. At the end of each worker thread, if there is a fscache on the primary thread, merge the cached results from the worker into the primary thread cache. This enables us to reuse the cache later especially when scanning for untracked files. In testing, this reduced the time spent in preload_index() by about 25% and also reduced the CPU utilization significantly. On a repo with ~200K files, it reduced overall status times by ~12%. Signed-off-by: Ben Peart <[email protected]>
…e don't leak the memory and so that we can dump the fscache statistics. Signed-off-by: Ben Peart <[email protected]>
Track fscache hits and misses for lstat and opendir requests. Reporting of statistics is done when the cache is disabled for the last time and freed and is only reported if GIT_TRACE_FSCACHE is set. Sample output is: 11:33:11.836428 compat/win32/fscache.c:433 fscache: lstat 3775, opendir 263, total requests/misses 4052/269 Signed-off-by: Ben Peart <[email protected]>
Now that the fscache is single threaded, take advantage of the mem_pool as the allocator to significantly reduce the cost of allocations and frees. With the reduced cost of free, in future patches, we can start freeing the fscache at the end of commands instead of just leaking it. Signed-off-by: Ben Peart <[email protected]>
…-gfw fscache: use FindFirstFileExW to avoid retrieving the short name
…ter-status-gfw status: disable and free fscache at the end of the status command
…e-gfw fscache: add GIT_TEST_FSCACHE support
…ter-add-gfw At the end of the add command, disable and free the fscache
…ics-gfw fscache: add fscache hit statistics
When debugging Git, the criss-cross spawning of processes can make things quite a bit difficult, especially when a Unix shell script is thrown in the mix that calls a `git.exe` that then segfaults. To help debugging such things, we introduce the `open_in_gdb()` function which can be called at a code location where the segfault happens (or as close as one can get); This will open a new MinTTY window with a GDB that already attached to the current process. Inspired by Derrick Stolee. Signed-off-by: Johannes Schindelin <[email protected]>
This brings substantial wins in performance because the FSCache is now per-thread, being merged to the primary thread only at the end, so we do not have to lock (except while merging). Signed-off-by: Johannes Schindelin <[email protected]>
To support IPv6, Git provided fall back functions for Windows versions that did not support IPv6. However, as Git dropped support for Windows XP and prior, those functions are not needed anymore. Removed those fallbacks by reverting commit[1] and using the functions directly (without 'ipv6_' prefix). [1] fe3b2b7. Signed-off-by: tanushree27 <[email protected]>
Add a helper function to start GDB that was already attached to the current process
…fallback [Outreachy] Removed ipv6 fallback
dscho
force-pushed
the
rebase-to-v2.20.0-rc0
branch
from
34e7fc1 to
41dcf81
Compare
|
The failing tests (apart from the |
We do not actually need -mconsole; it is the default. But it hurts to have it, as it breaks the assumption of the mingw-w64-git package that it can reuse the flags to link git-bash.exe. So let's remove it. Signed-off-by: Johannes Schindelin <[email protected]>
|
Git for Windows v2.20.0-rc0 was released, but since v2.19.2 was released afterwards, and since v2.19.2 32-bit seems to be broken, I'd rather wait with merging the v2.20.0-rc0 branch thicket. We may need to release a v2.19.2(2). |
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.
This is the big rebase. It reduces the non-merge commit count from 384 to 266, quite the reduction. Part of that is the work we did in #1884 (submitting patches to the Git mailing list), part is the clean-up revolving around FSCache/MSVC/Visual Studio support.
This PR mainly serves as vehicle to trigger the build & test on Azure Pipelines.