BRANCHES.md: Add explanation of branches and using forks #17

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 <johannes.schindelin@gmx.de>

The CreateProcessW() function does not really support spaces in its first argument, lpApplicationName. But it supports passing NULL as lpApplicationName, which makes it figure out the application from the (possibly quoted) first argument of lpCommandLine. Let's use that trick (if we are certain that the first argument matches the executable's path) to support launching programs whose path contains spaces. This fixes https://github.com/git-for-windows/git/issue/692 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Teach FSCACHE to remember "not found" directories. This is a performance optimization. FSCACHE is a performance optimization available for Windows. It intercepts Posix-style lstat() calls into an in-memory directory using FindFirst/FindNext. It improves performance on Windows by catching the first lstat() call in a directory, using FindFirst/ FindNext to read the list of files (and attribute data) for the entire directory into the cache, and short-cut subsequent lstat() calls in the same directory. This gives a major performance boost on Windows. However, it does not remember "not found" directories. When STATUS runs and there are missing directories, the lstat() interception fails to find the parent directory and simply return ENOENT for the file -- it does not remember that the FindFirst on the directory failed. Thus subsequent lstat() calls in the same directory, each re-attempt the FindFirst. This completely defeats any performance gains. This can be seen by doing a sparse-checkout on a large repo and then doing a read-tree to reset the skip-worktree bits and then running status. This change reduced status times for my very large repo by 60%. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

A ton of Git commands simply do not read (or at least parse) the core.* settings. This is not good, as Git for Windows relies on the core.longPaths setting to be read quite early on. So let's just make sure that all commands read the config and give platform_core_config() a chance. This patch teaches tons of Git commands to respect the config setting `core.longPaths = true`, including `pack-refs`, thereby fixing git-for-windows#1218 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Teach read_directory_recursive() and add_excludes() to be aware of optional fscache and avoid trying to open() and fstat() non-existant ".gitignore" files in every directory in the worktree. The current code in add_excludes() calls open() and then fstat() for a ".gitignore" file in each directory present in the worktree. Change that when fscache is enabled to call lstat() first and if present, call open(). This seems backwards because both lstat needs to do more work than fstat. But when fscache is enabled, fscache will already know if the .gitignore file exists and can completely avoid the IO calls. This works because of the lstat diversion to mingw_lstat when fscache is enabled. This reduced status times on a 350K file enlistment of the Windows repo on a NVMe SSD by 0.25 seconds. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

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 <jeffhost@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Make fscache_enabled() function public rather than static. Remove unneeded fscache_is_enabled() function. Change is_fscache_enabled() macro to call fscache_enabled(). is_fscache_enabled() now takes a pathname so that the answer is more precise and mean "is fscache enabled for this pathname", since fscache only stores repo-relative paths and not absolute paths, we can avoid attempting lookups for absolute paths. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Fix regression described in: git-for-windows#1392 which was introduced in: git-for-windows@b235337 Problem Symptoms ================ When the user has a .gitignore file that is a symlink, the fscache optimization introduced above caused the stat-data from the symlink, rather that of the target file, to be returned. Later when the ignore file was read, the buffer length did not match the stat.st_size field and we called die("cannot use <path> as an exclude file") Optimization Rationale ====================== The above optimization calls lstat() before open() primarily to ask fscache if the file exists. It gets the current stat-data as a side effect essentially for free (since we already have it in memory). If the file does not exist, it does not need to call open(). And since very few directories have .gitignore files, we can greatly reduce time spent in the filesystem. Discussion of Fix ================= The above optimization calls lstat() rather than stat() because the fscache only intercepts lstat() calls. Calls to stat() stay directed to the mingw_stat() completly bypassing fscache. Furthermore, calls to mingw_stat() always call {open, fstat, close} so that symlinks are properly dereferenced, which adds *additional* open/close calls on top of what the original code in dir.c is doing. Since the problem only manifests for symlinks, we add code to overwrite the stat-data when the path is a symlink. This preserves the effect of the performance gains provided by the fscache in the normal case. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

When I do git fetch, git call file stats under .git/objects for each refs. This takes time when there are many refs. By enabling fscache, git takes file stats by directory traversing and that improved the speed of fetch-pack for repository having large number of refs. In my windows workstation, this improves the time of `git fetch` for chromium repository like below. I took stats 3 times. * With this patch TotalSeconds: 9.9825165 TotalSeconds: 9.1862075 TotalSeconds: 10.1956256 Avg: 9.78811653333333 * Without this patch TotalSeconds: 15.8406702 TotalSeconds: 15.6248053 TotalSeconds: 15.2085938 Avg: 15.5580231 Signed-off-by: Takuto Ikuta <tikuta@chromium.org>

This is retry of git-for-windows#1419. I added flush_fscache macro to flush cached stats after disk writing with tests for regression reported in git-for-windows#1438 and git-for-windows#1442. git checkout checks each file path in sorted order, so cache flushing does not make performance worse unless we have large number of modified files in a directory containing many files. Using chromium repository, I tested `git checkout .` performance when I delete 10 files in different directories. With this patch: TotalSeconds: 4.307272 TotalSeconds: 4.4863595 TotalSeconds: 4.2975562 Avg: 4.36372923333333 Without this patch: TotalSeconds: 20.9705431 TotalSeconds: 22.4867685 TotalSeconds: 18.8968292 Avg: 20.7847136 I confirmed this patch passed all tests in t/ with core_fscache=1. Signed-off-by: Takuto Ikuta <tikuta@chromium.org>

On file systems that support it, this can dramatically speed up operations like add, commit, describe, rebase, reset, rm that would otherwise have to lstat() every file to "re-match" the stat information in the index to that of the file system. On a synthetic repo with 1M files, "git reset" dropped from 52.02 seconds to 14.42 seconds for a savings of 72%. Signed-off-by: Ben Peart <benpeart@microsoft.com>

This branch introduces support for reading the "Windows-wide" Git configuration from `%PROGRAMDATA%\Git\config`. As these settings are intended to be shared between *all* Git-related software, that config file takes an even lower precedence than `$(prefix)/etc/gitconfig`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This will come in handy in the next commit. Signed-off-by: JiSeop Moon <zcube@zcube.kr> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a known issue that a rename() can fail with an "Access denied" error at times, when copying followed by deleting the original file works. Let's just fall back to that behavior. Signed-off-by: JiSeop Moon <zcube@zcube.kr> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

In preparation for making this function a bit more complicated (to allow for special-casing the `ContainerMappedDirectories` in Windows containers, which look like a symbolic link, but are not), let's move it out of the header. Signed-off-by: JiSeop Moon <zcube@zcube.kr> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

... even if they may look like them. As looking up the target of the "symbolic link" (just to see whether it starts with `/ContainerMappedDirectories/`) is pretty expensive, we do it when we can be *really* sure that there is a possibility that this might be the case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: JiSeop Moon <zcube@zcube.kr>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

From the documentation of said setting: This boolean will enable fsync() when writing object files. This is a total waste of time and effort on a filesystem that orders data writes properly, but can be useful for filesystems that do not use journalling (traditional UNIX filesystems) or that only journal metadata and not file contents (OS X’s HFS+, or Linux ext3 with "data=writeback"). The most common file system on Windows (NTFS) does not guarantee that order, therefore a sudden loss of power (or any other event causing an unclean shutdown) would cause corrupt files (i.e. files filled with NULs). Therefore we need to change the default. Note that the documentation makes it sound as if this causes really bad performance. In reality, writing loose objects is something that is done only rarely, and only a handful of files at a time. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The TerminateProcess() function does not actually leave the child processes any chance to perform any cleanup operations. This is bad insofar as Git itself expects its signal handlers to run. A symptom is e.g. a left-behind .lock file that would not be left behind if the same operation was run, say, on Linux. To remedy this situation, we use an obscure trick: we inject a thread into the process that needs to be killed and to let that thread run the ExitProcess() function with the desired exit status. Thanks J Wyman for describing this trick. The advantage is that the ExitProcess() function lets the atexit handlers run. While this is still different from what Git expects (i.e. running a signal handler), in practice Git sets up signal handlers and atexit handlers that call the same code to clean up after itself. In case that the gentle method to terminate the process failed, we still fall back to calling TerminateProcess(), but in that case we now also make sure that processes spawned by the spawned process are terminated; TerminateProcess() does not give the spawned process a chance to do so itself. Please note that this change only affects how Git for Windows tries to terminate processes spawned by Git's own executables. Third-party software that *calls* Git and wants to terminate it *still* need to make sure to imitate this gentle method, otherwise this patch will not have any effect. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Previously, we did not install any handler for Ctrl+C, but now we really want to because the MSYS2 runtime learned the trick to call the ConsoleCtrlHandler when Ctrl+C was pressed. With this, hitting Ctrl+C while `git log` is running will only terminate the Git process, but not the pager. This finally matches the behavior on Linux and on macOS. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

This topic branch conflicts with the next change that will change the way we call `CreateProcessW()`. So let's merge it early, to avoid merge conflicts during a merge (because we would have to resolve this with every single merging-rebase). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

By default, CreateProcess() does not inherit any open file handles, unless the bInheritHandles parameter is set to TRUE. Which we do need to set because we need to pass in stdin/stdout/stderr to talk to the child processes. Sadly, this means that all file handles (unless marked via O_NOINHERIT) are inherited. This lead to problems in GVFS Git, where a long-running read-object hook is used to hydrate missing objects, and depending on the circumstances, might only be called *after* Git opened a file handle. Ideally, we would not open files without O_NOINHERIT unless *really* necessary (i.e. when we want to pass the opened file handle as standard handle into a child process), but apparently it is all-too-easy to introduce incorrect open() calls: this happened, and prevented updating a file after the read-object hook was started because the hook still held a handle on said file. Happily, there is a solution: as described in the "Old New Thing" https://blogs.msdn.microsoft.com/oldnewthing/20111216-00/?p=8873 there is a way, starting with Windows Vista, that lets us define precisely which handles should be inherited by the child process. And since we bumped the minimum Windows version for use with Git for Windows to Vista with v2.10.1 (i.e. a *long* time ago), we can use this method. So let's do exactly that. We need to make sure that the list of handles to inherit does not contain duplicates; Otherwise CreateProcessW() would fail with ERROR_INVALID_ARGUMENT. While at it, stop setting errno to ENOENT unless it really is the correct value. Also, fall back to not limiting handle inheritance under certain error conditions (e.g. on Windows 7, which is a lot stricter in what handles you can specify to limit to). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This branch introduces support for reading the "Windows-wide" Git configuration from `%PROGRAMDATA%\Git\config`. As these settings are intended to be shared between *all* Git-related software, that config file takes an even lower precedence than `$(prefix)/etc/gitconfig`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Specify symlink type in .gitattributes

This helps with minimal installations such as MinGit that refuse to waste .zip real estate by shipping identical copies of builtins (.zip files do not support hard links). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The main idea of this patch is that even if we have to look up the absolute path of the script, if only the basename was specified as argv[0], then we should use that basename on the command line, too, not the absolute path. This patch will also help with the upcoming patch where we automatically substitute "sh ..." by "busybox sh ..." if "sh" is not in the PATH but "busybox" is: we will do that by substituting the actual executable, but still keep prepending "sh" to the command line. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

BusyBox comes with a ton of applets ("applet" being the identical concept to Git's "builtins"). And similar to Git's builtins, the applets can be called via `busybox <command>`, or the BusyBox executable can be copied/hard-linked to the command name. The similarities do not end here. Just as with Git's builtins, it is problematic that BusyBox' hard-linked applets cannot easily be put into a .zip file: .zip archives have no concept of hard-links and therefore would store identical copies (and also extract identical copies, "inflating" the archive unnecessarily). To counteract that issue, MinGit already ships without hard-linked copies of the builtins, and the plan is to do the same with BusyBox' applets: simply ship busybox.exe as single executable, without hard-linked applets. To accommodate that, Git is being taught by this commit a very special trick, exploiting the fact that it is possible to call an executable with a command-line whose argv[0] is different from the executable's name: when `sh` is to be spawned, and no `sh` is found in the PATH, but busybox.exe is, use that executable (with unchanged argv). Likewise, if any executable to be spawned is not on the PATH, but busybox.exe is found, parse the output of `busybox.exe --help` to find out what applets are included, and if the command matches an included applet name, use busybox.exe to execute it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Instead of relying on the presence of `make`, or `prove`, we might just as well use our own facilities to run the test suite. This helps e.g. when trying to verify a Git for Windows installation without requiring to download a full Git for Windows SDK (which would use up 600+ megabytes of bandwidth, and over a gigabyte of disk space). Of course, it still requires the test helpers to be build *somewhere*, and the Git version should at least roughly match the version from which the test suite comes. At the same time, this new way to run the test suite allows to validate that a BusyBox-backed MinGit works as expected (verifying that BusyBox' functionality is enough to at least pass the test suite). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is a bit strange, and even undesirable, to require Perl just to run the test suite even when NO_PERL was set. This patch does not fix this problem by any stretch of imagination. However, it fixes *the* Perl invocation that *every single* test script has to run. While at it, it makes the source code also more grep'able, as the code that unsets some, but not all, GIT_* environment variables just became a *lot* more explicit. And all that while still reducing the total number of lines. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This helper is slightly more performant than the script with MSYS2's Bash. And a lot more readable. To accommodate t1050, which wants to compare files weighing in with 3MB (falling outside of t1050's malloc limit of 1.5MB), we simply lift the allocation limit by setting the environment variable GIT_ALLOC_LIMIT to zero when calling the helper. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It is convenient to assume that everybody who wants to build & test Git has access to a working `iconv` executable (after all, we already pretty much require libiconv). However, that limits esoteric test scenarios such as Git for Windows', where an end user installation has to ship with `iconv` for the sole purpose of being testable. That payload serves no other purpose. So let's just have a test helper (to be able to test Git, the test helpers have to be available, after all) to act as `iconv` replacement. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea of copying README and COPYING into t/diff-lib/ was to step away from using files from outside t/ in tests. Let's really make sure that we use the files from t/diff-lib/ instead of other versions of those files. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

We already have a directory where we store files intended for use by multiple test scripts. The same directory is a better home for the test-binary-*.png files than t/. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The idea is to allow running the test suite on MinGit with BusyBox installed in /mingw64/bin/sh.exe. In that case, we will want to exclude sort & find (and other Unix utilities) from being bundled. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

BusyBox-w32 is a true Win32 application, i.e. it does not come with a POSIX emulation layer. That also means that it does *not* use the Unix convention of separating the entries in the PATH variable using colons, but semicolons. However, there are also BusyBox ports to Windows which use a POSIX emulation layer such as Cygwin's or MSYS2's runtime, i.e. using colons as PATH separators. As a tell-tale, let's use the presence of semicolons in the PATH variable: on Unix, it is highly unlikely that it contains semicolons, and on Windows (without POSIX emulation), it is virtually guaranteed, as everybody should have both $SYSTEMROOT and $SYSTEMROOT/system32 in their PATH. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Traditionally, Git for Windows' SDK uses Bash as its default shell. However, other Unix shells are available, too. Most notably, the Win32 port of BusyBox comes with `ash` whose `pwd` command already prints Windows paths as Git for Windows wants them, while there is not even a `builtin` command. Therefore, let's be careful not to override `pwd` unless we know that the `builtin` command is available. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The -W option is only understood by MSYS2 Bash's pwd command. We already make sure to override `pwd` by `builtin pwd -W` for MINGW, so let's not double the effort here. This will also help when switching the shell to another one (such as BusyBox' ash) whose pwd does *not* understand the -W option. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When running with BusyBox, we will want to avoid calling executables on the PATH that are implemented in BusyBox itself. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Since c6b0831 (docs: warn about possible '=' in clean/smudge filter process values, 2016-12-03), t0021 writes out a file with quotes in its name, and MSYS2's path conversion heuristics mistakes that to mean that we are not talking about a path here. Therefore, we need to use Windows paths, as the test-helper is a Win32 program that would otherwise have no idea where to look for the file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, it is impossible to create a file whose name contains a quote character. We already excluded test cases using such files from running on Windows when git.exe itself was tested. However, we still had two test cases that try to create such a file, and redirect stdin from such a file, respectively. This *seems* to work in Git for Windows' Bash due to an obscure feature inherited from Cygwin: illegal filename characters are simply mapped into/from a private UTF-8 page. Pure Win32 programs (such as git.exe) *still* cannot work with those files, of course, but at least Unix shell scripts pretend to be able to. This entire strategy breaks down when switching to any Unix shell lacking support for that private UTF-8 page trick, e.g. BusyBox-w32's ash. So let's just exclude test cases that test whether the Unix shell can redirect to/from files with "funny names" those from running on Windows, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Everybody and their dogs, cats and other pets settled on using unified diffs. It is a really quaint holdover from a long-gone era that GNU diff outputs "normal" diff by default. Yet, t4124 relied on that mode. This mode is so out of fashion in the meantime, though, that e.g. BusyBox' diff decided not even to bother to support it. It only supports unified diffs. So let's just switch away from "normal" diffs and use unified diffs, as we really are only interested in the `+` lines. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

At some stage, t5003-archive-zip wants to add a file that is not ASCII. To that end, it uses /bin/sh. But that file may actually not exist (it is too easy to forget that not all the world is Unix/Linux...)! Besides, we already have perfectly fine binary files intended for use solely by the tests. So let's use one of them instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

BusyBox' unzip is working pretty well. But Git's tests want to abuse it to not only extract files, but to convert their line endings on the fly, too. BusyBox' unzip does not support that, and it would appear that it would require rather intrusive changes. So let's just work around this by skipping the test case that uses `unzip -a` and the subsequent test cases expecting `unzip -a`'s output. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

While it may seem super convenient to some old Unix hands to simpy require Perl to be available when running the test suite, this is a major hassle on Windows, where we want to verify that Perl is not, actually, required in a NO_PERL build. As a super ugly workaround, we "install" a script into /usr/bin/perl reading like this: #!/bin/sh # We'd much rather avoid requiring Perl altogether when testing # an installed Git. Oh well, that's why we cannot have nice # things. exec c:/git-sdk-64/usr/bin/perl.exe "$@" The problem with that is that BusyBox assumes that the #! line in a script refers to an executable, not to a script. So when it encounters the line #!/usr/bin/perl in t5532's proxy-get-cmd, it barfs. Let's help this situation by simply executing the Perl script with the "interpreter" specified explicitly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When t5605 tries to verify that files are hardlinked (or that they are not), it uses the `-links` option of the `find` utility. BusyBox' implementation does not support that option, and BusyBox-w32's lstat() does not even report the number of hard links correctly (for performance reasons). So let's just switch to a different method that actually works on Windows. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Git for Windows uses MSYS2's Bash to run the test suite, which comes with benefits but also at a heavy price: on the plus side, MSYS2's POSIX emulation layer allows us to continue pretending that we are on a Unix system, e.g. use Unix paths instead of Windows ones, yet this is bought at a rather noticeable performance penalty. There *are* some more native ports of Unix shells out there, though, most notably BusyBox-w32's ash. These native ports do not use any POSIX emulation layer (or at most a *very* thin one, choosing to avoid features such as fork() that are expensive to emulate on Windows), and they use native Windows paths (usually with forward slashes instead of backslashes, which is perfectly legal in almost all use cases). And here comes the problem: with a $PWD looking like, say, C:/git-sdk-64/usr/src/git/t/trash directory.t5813-proto-disable-ssh Git's test scripts get quite a bit confused, as their assumptions have been shattered. Not only does this path contain a colon (oh no!), it also does not start with a slash. This is a problem e.g. when constructing a URL as t5813 does it: ssh://remote$PWD. Not only is it impossible to separate the "host" from the path with a $PWD as above, even prefixing $PWD by a slash won't work, as /C:/git-sdk-64/... is not a valid path. As a workaround, detect when $PWD does not start with a slash on Windows, and simply strip the drive prefix, using an obscure feature of Windows paths: if an absolute Windows path starts with a slash, it is implicitly prefixed by the drive prefix of the current directory. As we are talking about the current directory here, anyway, that strategy works. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

BusyBox' find implementation does not understand the -ls option, so let's not use it when we're running inside BusyBox. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

On Windows, the current working directory is pretty much guaranteed to contain a colon. If we feed that path to CVS, it mistakes it for a separator between host and port, though. This has not been a problem so far because Git for Windows uses MSYS2's Bash using a POSIX emulation layer that also pretends that the current directory is a Unix path (at least as long as we're in a shell script). However, that is rather limiting, as Git for Windows also explores other ports of other Unix shells. One of those is BusyBox-w32's ash, which is a native port (i.e. *not* using any POSIX emulation layer, and certainly not emulating Unix paths). So let's just detect if there is a colon in $PWD and punt in that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

In the BusyBox-w32 version that is currently under consideration for MinGit for Windows (to reduce the .zip size, and to avoid problems with the MSYS2 runtime), the UTF-16 environment present in Windows is considered to be authoritative, and the 8-bit version is always in UTF-8 encoding. As a consequence, the ISO-8859-1 test in t9350-fast-export (which tries to set GIT_AUTHOR_NAME to a ISO-8859-1 encoded value) *must* fail in that setup. So let's detect when it would fail (due to an environment being purely kept UTF-8 encoded), and skip that test in that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The Makefile target `install-mingit-test-artifacts` simply copies stuff and things directly into a MinGit directory, including an init.bat script to set everything up so that the tests can be run in a cmd window. Sadly, Git's test suite still relies on a Perl interpreter even if compiled with NO_PERL=YesPlease. We punt for now, installing a small script into /usr/bin/perl that hands off to an existing Perl of a Git for Windows SDK. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When trying to query the user directly via /dev/tty, both WSL's bash and BusyBox' bash emulation seem to have problems printing the value that they just read. The bash just stops in those instances, does not even execute any commands after the echo command. Let's just work around this by running the Bash snippet only in MSYS2's Bash: its `SHELL` variable has the `.exe` suffix, and neither WSL's nor BusyBox' bash set the `SHELL` variable to a path with that suffix. In the latter case, we simply exit with code 127 (indicating that the command was not found) and fall back to the CONIN$/CONOUT$ method quietly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

To support Git Bash running in a MinTTY, we use a dirty trick to access the MSYS2 pseudo terminal: we execute a Bash snippet that accesses /dev/tty. The idea was to fall back to writing to/reading from CONOUT$/CONIN$ if that Bash call failed because Bash was not found. However, we should fall back even in other error conditions, because we have not successfully read the user input. Let's make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

It turns out that when running in a Powershell window, we need to turn on ENABLE_ECHO_INPUT because the default would be *not* to echo anything. This also ensures that we use the input mode where all input is read until the user hits the Return key. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <dstolee@microsoft.com>

Includes touch-ups by Philip Oakley. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

With improvements by Clive Chan, Adric Norris, Ben Bodenmiller and Philip Oakley. Helped-by: Clive Chan <cc@clive.io> Helped-by: Adric Norris <landstander668@gmail.com> Helped-by: Ben Bodenmiller <bbodenmiller@hotmail.com> Helped-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Brendan Forster <brendan@github.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <philipoakley@iee.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

The sentiment bot will help detect when things get too heated. Hopefully. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <alejandro.barreto@ni.com>

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 <johannes.schindelin@gmx.de> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Implement `strbuf_join_argv()` to join arguments into a strbuf. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

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 <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Remove whitespaces after redirection operators and wrap long lines. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Rename some test cases' labels to be more descriptive and under 80 characters per line. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

This commit introduces tests for `git stash show` config. It tests all the cases where `stash.showStat` and `stash.showPatch` are unset or set to true / false. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Mention in the documentation, that `show` accepts any option known to `git diff`. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add a builtin helper for performing stash commands. Converting all at once proved hard to review, so starting with just apply lets conversion get started without the other commands being finished. The helper is being implemented as a drop in replacement for stash so that when it is complete it can simply be renamed and the shell script deleted. Delete the contents of the apply_stash shell function and replace it with a call to stash--helper apply until pop is also converted. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add the drop and clear commands to the builtin helper. These two are each simple, but are being added together as they are quite related. We have to unfortunately keep the drop and clear functions in the shell script as functions are called with parameters internally that are not valid when the commands are called externally. Once pop is converted they can both be removed. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash branch to the helper and delete the apply_to_branch function from the shell script. Checkout does not currently provide a function for checking out a branch as cmd_checkout does a large amount of sanity checks first that we require here. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash pop to the helper and delete the pop_stash, drop_stash, assert_stash_ref functions from the shell script now that they are no longer needed. Signed-off-by: Joel Teichroeb <joel@teichroeb.net> Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash list to the helper and delete the list_stash function from the shell script. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash show to the helper and delete the show_stash, have_stash, assert_stash_like, is_stash_like and parse_flags_and_rev functions from the shell script now that they are no longer needed. In shell version, although `git stash show` accepts `--index` and `--quiet` options, it ignores them. In C, both options are passed further to `git diff`. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash store to the helper and delete the store_stash function from the shell script. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash create to the helper. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash push to the helper. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

There is a change in behaviour with this commit. When there was no initial commit, the shell version of stash would still display a message. This commit makes `push` to not display any message if `--quiet` or `-q` is specified. Add tests for `--quiet`. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

Add stash save to the helper and delete functions which are no longer needed (`show_help()`, `save_stash()`, `push_stash()`, `create_stash()`, `clear_stash()`, `untracked_files()` and `no_changes()`). Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

The old shell script `git-stash.sh` was removed and replaced entirely by `builtin/stash.c`. In order to do that, `create` and `push` were adapted to work without `stash.sh`. For example, before this commit, `git stash create` called `git stash--helper create --message "$*"`. If it called `git stash--helper create "$@"`, then some of these changes wouldn't have been necessary. This commit also removes the word `helper` since now stash is called directly and not by a shell script. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

This commits introduces a optimization by avoiding calling the same functions again. For example, `git stash push -u` would call at some points the following functions: * `check_changes()` (inside `do_push_stash()`) * `do_create_stash()`, which calls: `check_changes()` and `get_untracked_files()` Note that `check_changes()` also calls `get_untracked_files()`. So, `check_changes()` is called 2 times and `get_untracked_files()` 3 times. The old function `check_changes()` now consists of two functions: `get_untracked_files()` and `check_changes_tracked_files()`. These are the call chains for `push` and `create`: * `push_stash()` -> `do_push_stash()` -> `do_create_stash()` * `create_stash()` -> `do_create_stash()` To prevent calling the same functions over and over again, `check_changes()` inside `do_create_stash()` is now placed in the caller functions (`create_stash()` and `do_push_stash()`). This way `check_changes()` and `get_untracked files()` are called only one time. https://public-inbox.org/git/20180818223329.GJ11326@hank.intra.tgummerer.com/ Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

This commit replaces spawning `git write-tree` with API calls. Signed-off-by: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

In the next commit, we want to make use of it in `run_am()` (i.e. running the `--am` backend directly, without detouring to Unix shell script code) which in turn will be called from `run_specific_rebase()`. So let's move it before that latter function. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When switching a branch *and* updating said branch to a different revision, let's avoid a double entry by first updating the branch and then adjusting the symbolic ref HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

While the scripted `git rebase` still has to rely on the `git-rebase--am.sh` script to implement the glue between the `rebase` and the `am` commands, we can go a more direct route in the builtin rebase and avoid using a shell script altogether. This reduces the chances of Git for Windows running into trouble due to problems with the POSIX emulation layer (known as "MSYS2 runtime", itself a derivative of the Cygwin runtime): when no shell script is called, the POSIX emulation layer is avoided altogether. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

This is the branch thicket of patches in Git for Windows that are considered ready for upstream. To keep them in a ready-to-submit shape, they are kept as close to the beginning of the branch thicket as possible.

These are Git for Windows' Git GUI and gitk patches. We will have to decide at some point what to do about them, but that's a little lower priority (as Git GUI seems to be unmaintained for the time being, and the gitk maintainer keeps a very low profile on the Git mailing list, too). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Specify symlink type in .gitattributes

This branch introduces support for reading the "Windows-wide" Git configuration from `%PROGRAMDATA%\Git\config`. As these settings are intended to be shared between *all* Git-related software, that config file takes an even lower precedence than `$(prefix)/etc/gitconfig`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Allow `add -p` and `add -i` with a large number of files

This addresses git-for-windows#521 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This change lets us spawn .bat scripts whose paths contain spaces. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…er/fscache_nfd fscache: add not-found directory cache to fscache

Git for Windows supports the core.longPaths config setting to allow writing/reading long paths via the \\?\ trick for a long time now. However, for that support to work, it is absolutely necessary that git_default_config() is given a chance to parse the config. Otherwise Git will be non the wiser. So let's make sure that as many commands that previously failed to parse the core.* settings now do that, implicitly enabling long path support in a lot more places. Note: this is not a perfect solution, and it cannot be, as there is a chicken-and-egg problem in reading the config itself... This fixes git-for-windows#1218 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…er/add_preload_fscache add: use preload-index and fscache for performance

…xcludes_with_fscache dir.c: make add_excludes aware of fscache during status

fetch-pack.c: enable fscache for stats under .git/objects

…t_flush checkout.c: enable fscache for checkout again Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…_index Enable the filesystem cache (fscache) in refresh_index().

This was pull request git-for-windows#1645 from ZCube/master Support windows container. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This branch allows third-party tools to call `git status --no-lock-index` to avoid lock contention with the interactive Git usage of the actual human user. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…ored-directory-gracefully Phase out `--show-ignored-directory` gracefully

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Handle Ctrl+C in Git Bash nicely Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

When spawning child processes, we do want them to inherit the standard handles so that we can talk to them. We do *not* want them to inherit any other handle, as that would hold a lock to the respective files (preventing them from being renamed, modified or deleted), and the child process would not know how to access that handle anyway. Happily, there is an API to make that happen. It is supported in Windows Vista and later, which is exactly what we promise to support in Git for Windows for the time being. This also means that we lift, at long last, the target Windows version from Windows XP to Windows Vista. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This topic branch brings slightly experimental changes supporting Git for Windows to use BusyBox-w32 to execute its shell scripts as well as its test suite. The test suite can be run by installing the test artifacts into a MinGit that has busybox.exe (and using Git for Windows' SDK's Perl for now, as the test suite requires Perl even when NO_PERL is set, go figure) by using the `install-mingit-test-artifacts` Makefile target with the DESTDIR variable pointing to the top-level directory of the MinGit installation. To facilitate running the test suite (without having `make` available, as `make.exe` is not part of MinGit), this branch brings an experimental patch to the `test-run-command` helper to run Git's test suite. It is still very experimental, though: in this developer's tests it seemed that the `poll()` emulation required for `run_parallel_processes()` to work sometimes hiccups on Windows, causing infinite "hangs". It is also possible that BusyBox itself has problems writing to the pipes opened by `test-run-command` (and merging this branch will help investigate further). Caveat emptor. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This fixes the issue identified in git-for-windows#1498 where Git would not fall back to reading credentials from a Win32 Console when the credentials could not be read from the terminal via the Bash hack (that is necessary to support running in a MinTTY). Tested in a Powershell window. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Add a README.md for GitHub goodness. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

Fix t0001 when the current working directory differs in case from the canonical form

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 <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

Add support to fscache to enable running the entire test suite with the fscache enabled. Signed-off-by: Ben Peart <benpeart@microsoft.com>

…e don't leak the memory and so that we can dump the fscache statistics. Signed-off-by: Ben Peart <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

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 <benpeart@microsoft.com>

…-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

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 <johannes.schindelin@gmx.de>

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 <johannes.schindelin@gmx.de>

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 <tanushreetumane@gmail.com>

The recent change to make fscache thread specific relied on fscache_enable() being called first from the primary thread before being called in parallel from worker threads. Make that more robust and protect it with a critical section to avoid any issues. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Ben Peart <benpeart@microsoft.com>

Using FindFirstFileExW() requires the OS to allocate a 64K buffer for each directory and then free it when we call FindClose(). Update fscache to call the underlying kernel API NtQueryDirectoryFile so that we can do the buffer management ourselves. That allows us to allocate a single buffer for the lifetime of the cache and reuse it for each directory. This change improves performance of 'git status' by 18% in a repo with ~200K files and 30k folders. Documentation for NtQueryDirectoryFile can be found at: https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntifs/nf-ntifs-ntquerydirectoryfile https://docs.microsoft.com/en-us/windows/desktop/FileIO/file-attribute-constants https://docs.microsoft.com/en-us/windows/desktop/fileio/reparse-point-tags To determine if the specified directory is a symbolic link, inspect the FileAttributes member to see if the FILE_ATTRIBUTE_REPARSE_POINT flag is set. If so, EaSize will contain the reparse tag (this is a so far undocumented feature, but confirmed by the NTFS developers). To determine if the reparse point is a symbolic link (and not some other form of reparse point), test whether the tag value equals the value IO_REPARSE_TAG_SYMLINK. Signed-off-by: Ben Peart <benpeart@microsoft.com>

Add a helper function to start GDB that was already attached to the current process

…fallback [Outreachy] Removed ipv6 fallback

We cannot rely on `uname -m` in Git for Windows' SDK to tell us what architecture we are compiling for, as we can compile both 32-bit and 64-bit `git.exe` from a 64-bit SDK, but the `uname -m` in that SDK will always report `x86_64`. So let's go back to our original design. And make it explicitly Windows-specific. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

…safe-enable-gfw fscache: make fscache_enable() thread safe

…DirectoryFile-gfw fscache: teach fscache to use NtQueryDirectoryFile

For many Win32 functions, there actually exist two variants: one with the `A` suffix that takes ANSI parameters (`char *` or `const char *`) and one with the `W` suffix that takes Unicode parameters (`wchar_t *` or `const wchar_t *`). Let's be precise what we want to use. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

mingw: safeguard against compiling with `-DUNICODE`

Usually we don't need to set libcurl to choose which version of the HTTP protocol to use to communicate with a server. But different versions of libcurl, the default value is not the same. CURL >= 7.62.0: CURL_HTTP_VERSION_2TLS CURL < 7.62: CURL_HTTP_VERSION_1_1 In order to give users the freedom to control the HTTP version, we need to add a setting to choose which HTTP version to use. Signed-off-by: Force Charlie <charlieio@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

http: add support selecting http version

Pointed out by our cocci job. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

This is just a bug fix to git so that the pager won't close stdin/out before other atexit functions run. The easy way to repro the bug is to turn on GIT_TRACE_PERFORMANCE and run a command that runs the pager. Then notice you don't get your performance data at the end. With this fix, you do actually get the performance trace data. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

While using the reset --stdin feature on windows path added may have a \r at the end of the path that wasn't getting removed so didn't match the path in the index and wasn't reset. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

Signed-off-by: Saeed Noursalehi <sanoursa@microsoft.com>

When using the sparse-checkout feature, the file might not be on disk because the skip-worktree bit is on. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

When using the sparse-checkout feature git should not write to the working directory for files with the skip-worktree bit on. With the skip-worktree bit on the file may or may not be in the working directory and if it is not we don't want or need to create it by calling checkout_entry. There are two callers of checkout_target. Both of which check that the file does not exist before calling checkout_target. load_current which make a call to lstat right before calling checkout_target and check_preimage which will only run checkout_taret it stat_ret is less than zero. It sets stat_ret to zero and only if !stat->cached will it lstat the file and set stat_ret to something other than zero. This patch checks if skip-worktree bit is on in checkout_target and just returns so that the entry doesn't not end up in the working directory. This is so that apply will not create a file in the working directory, then update the index but not keep the working directory up to date with the changes that happened in the index. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

When using the sparse checkout feature the git reset command will add entries to the index that will have the skip-worktree bit off but will leave the working directory empty. File data is lost because the index version of the files has been changed but there is nothing that is in the working directory. This will cause the next status call to show either deleted for files modified or deleting or nothing for files added. The added files should be shown as untracked and modified files should be shown as modified. To fix this when the reset is running if there is not a file in the working directory and if it will be missing with the new index entry or was not missing in the previous version, we create the previous index version of the file in the working directory so that status will report correctly and the files will be availble for the user to deal with. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

The multi-pack-index was added to the data verified by git-fsck in ea5ae6c "fsck: verify multi-pack-index". This implementation was based on the implementation for verifying the commit-graph, and a copy-paste error kept the ERROR_COMMIT_GRAPH flag as the bit set when an error appears in the multi-pack-index. Add a new flag, ERROR_MULTI_PACK_INDEX, and use that instead. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

Signed-off-by: Johannes Schindelin <johasc@microsoft.com>

This header file will accumulate GVFS-specific definitions. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

This does not do anything yet. The next patches will add various values for that config setting that correspond to the various features offered/required by GVFS. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

This takes a substantial amount of time, and if the user is reasonably sure that the files' integrity is not compromised, that time can be saved. Git no longer verifies the SHA-1 by default, anyway. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

Signed-off-by: Kevin Willford <kewillf@microsoft.com>

The two existing members of the run_hook*() family, run_hook_ve() and run_hook_le(), are good for callers that know the precise number of parameters already. Let's introduce a new sibling that takes an argv array for callers that want to pass a variable number of parameters. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Prevent the sparse checkout to delete files that were marked with skip-worktree bit and are not in the sparse-checkout file. This is because everything with the skip-worktree bit turned on is being virtualized and will be removed with the change of HEAD. There was only one failing test when running with these changes that was checking to make sure the worktree narrows on checkout which was expected since we would no longer be narrowing the worktree. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

The idea is to allow blob objects to be missing from the local repository, and to load them lazily on demand. After discussing this idea on the mailing list, we will rename the feature to "lazy clone" and work more on this. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

While performing a fetch with a virtual file system we know that there will be missing objects and we don't want to download them just because of the reachability of the commits. We also don't want to download a pack file with commits, trees, and blobs since these will be downloaded on demand. This flag will skip the first connectivity check and by returning zero will skip the upload pack. It will also skip the second connectivity check but continue to update the branches to the latest commit ids. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

Hydrate missing loose objects in check_and_freshen() when running virtualized. Add test cases to verify read-object hook works when running virtualized. This hook is called in check_and_freshen() rather than check_and_freshen_local() to make the hook work also with alternates. Helped-by: Kevin Willford <kewillf@microsoft.com> Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

Ensure all filters and EOL conversions are blocked when running under GVFS so that our projected file sizes will match the actual file size when it is hydrated on the local machine. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

This adds hard-coded call to GVFS.hooks.exe before and after each Git command runs. To make sure that this is only called on repositories cloned with GVFS, we test for the tell-tale .gvfs. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

The use case here is to allow usage statistics to be gathered by running hooks before and after every hook, and to make that configurable via hooks. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

GVFS Git introduced pre-command and post-command hooks, to gather usage statistics and to be able to adjust the worktree if necessary. As run_hooks() implicitly calls setup_git_directory(), and that function does surprising things to the global state (sometimes even changing the current working directory), it cannot be used here. This commit introduces the pre-command/post-command hooks, based on the previous patches that culminate in support for running hooks early, i.e. before setup_git_directory() was called. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

…ng objects This commit converts the existing read_object hook proc model for downloading missing blobs to use a background process that is started the first time git encounters a missing blob and stays running until git exits. Git and the read-object process communicate via stdin/stdout and a versioned, capability negotiated interface as documented in Documentation/technical/read-object-protocol.txt. The advantage of this over the previous hook proc is that it saves the overhead of spawning a new hook process for every missing blob. The model for the background process was refactored from the recent git LFS work. I refactored that code into a shared module (sub-process.c/h) and then updated convert.c to consume the new library. I then used the same sub-process module when implementing the read-object background process. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

Suggested by Ben Peart. Signed-off-by: Johannes Schindelin <johasc@microsoft.com>

If we are going to write an object there is no use in calling the read object hook to get an object from a potentially remote source. We would rather just write out the object and avoid the potential round trip for an object that doesn't exist. This change adds a flag to the check_and_freshen() and freshen_loose_object() functions' signatures so that the hook is bypassed when the functions are called before writing loose objects. The check for a local object is still performed so we don't overwrite something that has already been written to one of the objects directories. Based on a patch by Kevin Willford. Signed-off-by: Johannes Schindelin <johasc@microsoft.com>

Signed-off-by: Alejandro Pauly <alpauly@microsoft.com>

We need to respect that config setting even if we already know that we have a repository, but have not yet read the config. The regression test was written by Alejandro Pauly. Signed-off-by: Johannes Schindelin <johasc@microsoft.com>

Signed-off-by: Kevin Willford <kewillf@microsoft.com>

This code change makes sure that the config value for core_gvfs is always loaded before checking it. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

Teach STATUS to optionally serialize the results of a status computation to a file. Teach STATUS to optionally read an existing serialization file and simply print the results, rather than actually scanning. This is intended for immediate status results on extremely large repos and assumes the use of a service/daemon to maintain a fresh current status snapshot. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

String formatting can be a performance issue when there are hundreds of thousands of trees. Change to stop using the strbuf_addf and just add the strings or characters individually. There are a limited number of modes so added a switch for the known ones and a default case if something comes through that are not a known one for git. In one scenario regarding a huge worktree, this reduces the time required for a `git checkout <branch>` from 44 seconds to 38 seconds, i.e. it is a non-negligible performance improvement. Signed-off-by: Kevin Willford <kewillf@microsoft.com>

Add "status.aheadbehind" config setting to change the default behavior of ALL git status formats. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

…al format Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Teach porcelain V[12] formats to ignore the status.aheadbehind config setting. They only respect the --[no-]ahead-behind command line argument. This is for backwards compatibility with existing scripts. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Teach status serialization to take an optional pathname on the command line to direct that cache data be written there rather than to stdout. When used this way, normal status results will still be written to stdout. When no path is given, only binary serialization data is written to stdout. Usage: git status --serialize[=<path>] Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Teach status deserialize code to reject status cache when printing in porcelain V2 and there are unresolved conflicts in the cache file. A follow-on task might extend the cache format to include this additiona data. See code for longer explanation. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

Also include fetch.showForcedUpdates config setting that is overridden by the command-line arguments. Shows a warning when skipping the work. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

On index load, clear/set the skip worktree bits based on the virtual file system data. Use virtual file system data to update skip-worktree bit in unpack-trees. Use virtual file system data to exclude files and folders not explicitly requested. Signed-off-by: Ben Peart <benpeart@microsoft.com>

Move the warning about `--[no-]show-forced-updates` to the end of the branch update list. Also, show a different message when a lot of time is spent walking the commits. (Note, this time will not include the loose object downloads for the tip commits, but may include some loose object downloads for the reachable commits.)

We now specify that it needs to be run from the root of the git work tree. This enables the hook to be found even if the current working directory is not the root of the repo (like when running 'git diff' with Beyond Compare configured as the diff tool. Also simpify how argv[] parameter is created. Signed-off-by: Ben Peart <benpeart@microsoft.com>

Add virtual file system settings and hook proc. On index load, clear/set the skip worktree bits based on the virtual file system data. Use virtual file system data to update skip-worktree bit in unpack-trees. Use virtual file system data to exclude files and folders not explicitly requested. Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

The method pop_most_recent_commit() is confusingly named, in that it pops the most-recent commit, but also adds that commit's parents to the list. This is used by a few commit walks, especially the one in ref_newer(). 'git push' uses ref_newer() to check if a force-push is necessary, and in the case of a force-push being needed, the current algorithm walks every reachable commit. This is especially severe in the case of an amended commit: they have the same parent, but we still walk to the very end of the graph! Add a 'min_generation' parameter to pop_most_recent_commit() to limit the commits that are walked to those with generation number at least 'min_generation'. This greatly reduces the number of commits walked by a force-push. There may be more work to improve this algorithm in the future, but for now this is enough for most cases. This direction has the benefit that it does not affect the non-force-push case at all. Future directions should consider improving that case as well. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

Update the virtualfilesystem support to specify it needs to be run from the root of the git work tree. This enables the hook to be found even if the current working directory is not the root of the repo (like when running 'git diff' with Beyond Compare configured as the diff tool). Also simplify how argv[] parameter is created to match the model currently accepted in master.

Revert the previous commits involving generation numbers and apply the commits that are in upstream `next`.

Fix "git status --deserialize" to correctly report both pathnames for renames. Add a test case to verify. A change was made upstream that added an additional "rename_status" field to the "struct wt_status_change_data" structure. It is used during the various print routines to decide if 2 pathnames need to be printed. 5134ccd wt-status.c: rename rename-related fields in wt_status_change_data The fix here is to add that field to the status cache data. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

The "ahead_behind_flags" field of "struct wt_status" does not need to be stored in the serialization cache file, since it is a display property. Update the code comments in both serialize and deserialize to reflect that. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Changes to the global or repo-local excludes files can change the results returned by "git status" for untracked files. Therefore, it is important that the exclude-file values used during serialization are still current at the time of deserialization. Teach "git status --serialize" to report metadata on the user's global exclude file (which defaults to "$XDG_HOME/git/ignore") and for the repo-local excludes file (which is in ".git/info/excludes"). Serialize will record the pathnames and mtimes for these files in the serialization header (next to the mtime data for the .git/index file). Teach "git status --deserialize" to validate this new metadata. If either exclude file has changed since the serialization-cache-file was written, then deserialize will reject the cache file and force a full/normal status run. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

…us-rename GVFS serialize status updates

Teach `git status --deserialize` to either wait indefintely or immediately fail if the status serialization cache file is stale. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

serialize-status: serialize global and repo-local exclude file metadata

…x has been redirected Fixes microsoft#13 Some git commands spawn helpers and redirect the index to a different location. These include "difftool -d" and the sequencer (i.e. `git rebase -i`, `git cherry-pick` and `git revert`) and others. In those instances we don't want to update their temporary index with our virtualization data. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

…ze-wait status: deserialization wait

The virtual file system code incorrectly treated symlinks as directories instead of regular files. This meant symlinks were not included even if they are listed in the list of files returned by the core.virtualFilesystem hook proc. Fixes microsoft#25 Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>

virtualfilesystem: don't run the virtual file system hook if the index has been redirected

virtualfilesystem: fix bug with symlinks being ignored

Create a new unified tracing facility for git. The eventual intent is to replace the current trace_printf* and trace_performance* routines with a unified set of git_trace2* routines. In addition to the usual printf-style API, trace2 provides higer-level event verbs with fixed-fields allowing structured data to be written. This makes post-processing and analysis easier for external tools. Trace2 defines 3 output targets. These are set using the environment variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT". These may be set to "1" or to an absolute pathname (just like the current GIT_TRACE). * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command summary data. * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE. It extends the output with columns for the command process, thread, repo, absolute and relative elapsed times. It reports events for child process start/stop, thread start/stop, and per-thread function nesting. * GIT_TR2_EVENT is a new structured format. It writes event data as a series of JSON records. Calls to trace2 functions log to any of the 3 output targets enabled without the need to call different trace_printf* or trace_performance* routines. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Add trace2_region_enter() and trace2_region_leave() calls around the various phases of a status scan. This gives elapsed time for each phase in the GIT_TR2_PERF and GIT_TR2_EVENT trace target. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Classify editor, pager, and sub-process child processes. The former two can be used to identify interactive commands, for example. A later effort could classify other types of commands, such as "gc", "hook", and etc. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Add trace2 events when reading and writing the index. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Add trace2 region and data events describing attempts to deserialize status data using a status cache. A category:status, label:deserialize region is pushed around the deserialize code. Deserialization results when reading from a file are: category:status, path = <path> category:status, polled = <number_of_attempts> category:status, result = "ok" | "reject" When reading from STDIN are: category:status, path = "STDIN" category:status, result = "ok" | "reject" Status will fallback and run a normal status scan when a "reject" is reported (unless "--deserialize-wait=fail"). If "ok" is reported, status was able to use the status cache and avoid scanning the workdir. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

Add check to see if a directory is included in the virtualfilesystem before checking the directory hashmap. This allows a directory entry like foo/ to find all untracked files in subdirectories.

Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>

…y is included Add check to see if a directory is included in the virtualfilesystem before checking the directory hashmap. This allows a directory entry like foo/ to find all untracked files in subdirectories.

When studying the performance of 'git push' we would like to know how much time is spent at various parts of the command. One area that could cause performance trouble is 'git pack-objects'. Add trace2 regions around the three main actions taken in this command: 1. Enumerate objects. 2. Prepare pack. 3. Write pack-file. Signed-off-by: Derrick Stolee <dstolee@microsoft.com>

(Experimental) Trace2 base plus GVFS extensions

We want to make `git push` faster, but we need to know where the time is going! There are likely four places where the time is going: 1. The info/refs call and force-update checking at the beginning. 2. The `git pack-objects` call that creates a pack-file to send to the server. 3. Sending the data to the server. 4. Waiting for the server to verify the pack-file. This PR adds `trace2_region_` calls inside `git pack-objects` so we can track the time in item (2). The rest could be interpreted from the start and end time of the entire command after we know this region. The server-side verification is something we can track using server telemetry.

William Baker reported that the non-built-in rebase and stash fail to run the post-command hook (which is important for VFS for Git, though). The reason is that an `exec()` will replace the current process by the newly-exec'ed one (our Windows-specific emulation cannot do that, and does not even try, so this is only an issue on Linux/macOS). As a consequence, not even the atexit() handlers are run, including the one running the post-command hook. To work around that, let's spawn the legacy rebase/stash and exit with the reported exit code.

…port

…nd `git stash` William Baker reported that the non-built-in rebase and stash fail to run the post-command hook (which is important for VFS for Git, though). The reason is that an `exec()` will replace the current process by the newly-exec'ed one (our Windows-specific emulation cannot do that, and does not even try, so this is only an issue on Linux/macOS). As a consequence, not even the atexit() handlers are run, including the one running the post-command hook. To work around that, let's spawn the legacy rebase/stash and exit with the reported exit code.

…pstream This includes commits that fixup!-revert all the midx-related commits from our GVFS branch and replaces them with the exact commits that are being merged upstream. This should automatically remove the commits during our next version rebase-and-merge action. Changes upstream: - The builtin is called 'git multi-pack-index'. - The command-line takes a 'write' verb and an '--object-dir' parameter. - We no longer have a 'midx-head' or '*.midx' files. - Instead, we have a 'multi-pack-index' file in the pack-dir. - It no longer makes sense to specify '--update-head'

…when GVFS_MISSING_OK set send-pack: do not check for sha1 file when GVFS_MISSING_OK set

The vfs does not correctly handle the case when there is a file that begins with the same prefix as a directory. For example, the following setup would encounter this issue: A directory contains a file named `dir1.sln` and a directory named `dir1/`. The directory `dir1` contains other files. The directory `dir1` is in the virtual file system list The contents of `dir1` should be in the virtual file system, but it is not. The contents of this directory do not have the skip worktree bit cleared as expected. The problem is in the `apply_virtualfilesystem(...)` function where it does not include the trailing slash of the directory name when looking up the position in the index to start clearing the skip worktree bit. This fix is it include the trailing slash when finding the first index entry from `index_name_pos(...)`.

Index changed hook

…_directories virtualfilesystem: fix case where directories not handled correctly

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

BRANCHES.md: Add explanation of branches and using forks #17

BRANCHES.md: Add explanation of branches and using forks #17

Commits on Dec 9, 2018

Commits on Dec 10, 2018

Commits on Dec 11, 2018