Shears/next #2356
Closed
Shears/next #2356
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
When displaying the only hunk in a file's diff, the prompt already excludes the commands to navigate to the previous/next hunk. Let's also let the `?` command show only the help lines corresponding to the commands that are displayed in the prompt. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `git stash` and `git reset` commands support a `--patch` option, and both simply hand off to `git add -p` to perform that work. Let's teach the built-in version of `git add -p` do perform that work, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch will make `git add -p` show "No changes." or "Only binary files changed." in that case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Perl version supports post-processing the colored diff (that is generated in addition to the uncolored diff, intended to offer a prettier user experience) by a command configured via that config setting, and now the built-in version does that, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Perl version of `git add -p` reads the config setting `diff.algorithm` and if set, uses it to generate the diff using the specified algorithm. This patch ports that functionality to the C version. To make sure that this works as intended, we add a regression test case that tries to specify a bogus diff algorithm and then verifies that `git diff-files` produced the expected error message. Note: In that new test case, we actually ignore the exit code of `git add -p`. The reason is that the C version exits with failure (as one might expect), but the Perl version does not. In fact, the Perl version continues happily after the uncolored diff failed, trying to generate the colored diff, still not catching the problem, and then it pretends to have succeeded (with exit code 0). This is arguably a bug in the Perl version, and fixing it is safely outside the scope of this patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We are about to introduce the function `enable_non_canonical()`, which shares almost the complete code with `disable_echo()`. Let's prepare for that, by refactoring out that shared code. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git for Windows' Git Bash runs in MinTTY by default, which does not have a Win32 Console instance, but uses MSYS2 pseudo terminals instead. This is a problem, as Git for Windows does not want to use the MSYS2 emulation layer for Git itself, and therefore has no direct way to interact with that pseudo terminal. As a workaround, use the `stty` utility (which is included in Git for Windows, and which *is* an MSYS2 program, so it knows how to deal with the pseudo terminal). Note: If Git runs in a regular CMD or PowerShell window, there *is* a regular Win32 Console to work with. This is not a problem for the MSYS2 `stty`: it copes with this scenario just fine. Also note that we introduce support for more bits than would be necessary for a mere `disable_echo()` here, in preparation for the upcoming `enable_non_canonical()` function. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Typically, input on the command-line is line-based. It is actually not really easy to get single characters (or better put: keystrokes). We provide two implementations here: - One that handles `/dev/tty` based systems as well as native Windows. The former uses the `tcsetattr()` function to put the terminal into "raw mode", which allows us to read individual keystrokes, one by one. The latter uses `stty.exe` to do the same, falling back to direct Win32 Console access. Thanks to the refactoring leading up to this commit, this is a single function, with the platform-specific details hidden away in conditionally-compiled code blocks. - A fall-back which simply punts and reads back an entire line. Note that the function writes the keystroke into an `strbuf` rather than a `char`, in preparation for reading Escape sequences (e.g. when the user hit an arrow key). This is also required for UTF-8 sequences in case the keystroke corresponds to a non-ASCII letter. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch teaches the built-in `git add -p` machinery all the tricks it needs to know in order to act as the work horse for `git checkout -p`. Apart from the minor changes (slightly reworded messages, different `diff` and `apply --check` invocations), it requires a new function to actually apply the changes, as `git checkout -p` is a bit special in that respect: when the desired changes do not apply to the index, but apply to the work tree, Git does not fail straight away, but asks the user whether to apply the changes to the worktree at least. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Perl version of `git add -p` supports this config setting to allow users to input commands via single characters (as opposed to having to press the <Enter> key afterwards). This is an opt-in feature because it requires Perl packages (Term::ReadKey and Term::Cap, where it tries to handle an absence of the latter package gracefully) to work. Note that at least on Ubuntu, that Perl package is not installed by default (it needs to be installed via `sudo apt-get install libterm-readkey-perl`), so this feature is probably not used a whole lot. In C, we obviously do not have these packages available, but we just introduced `read_single_keystroke()` that is similar to what Term::ReadKey provides, and we use that here. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a straight-forward port of 2f0896e (restore: support --patch, 2019-04-25) which added support for `git restore -p`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This recapitulates part of b5cc003 (add -i: ignore terminal escape sequences, 2011-05-17): add -i: ignore terminal escape sequences On the author's terminal, the up-arrow input sequence is ^[[A, and thus fat-fingering an up-arrow into 'git checkout -p' is quite dangerous: git-add--interactive.perl will ignore the ^[ and [ characters and happily treat A as "discard everything". As a band-aid fix, use Term::Cap to get all terminal capabilities. Then use the heuristic that any capability value that starts with ^[ (i.e., \e in perl) must be a key input sequence. Finally, given an input that starts with ^[, read more characters until we have read a full escape sequence, then return that to the caller. We use a timeout of 0.5 seconds on the subsequent reads to avoid getting stuck if the user actually input a lone ^[. Since none of the currently recognized keys start with ^[, the net result is that the sequence as a whole will be ignored and the help displayed. Note that we leave part for later which uses "Term::Cap to get all terminal capabilities", for several reasons: 1. it is actually not really necessary, as the timeout of 0.5 seconds should be plenty sufficient to catch Escape sequences, 2. it is cleaner to keep the change to special-case Escape sequences separate from the change that reads all terminal capabilities to speed things up, and 3. in practice, relying on the terminal capabilities is a bit overrated, as the information could be incomplete, or plain wrong. For example, in this developer's tmux sessions, the terminal capabilities claim that the "cursor up" sequence is ^[M, but the actual sequence produced by the "cursor up" key is ^[[A. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The built-in `git add -i` machinery obviously has its `the_repository` structure initialized at the point where `cmd_commit()` calls it, and therefore does not look at the environment variable `GIT_INDEX_FILE`. But it has to, because the index was already locked, and we want to ask the interactive add machinery to work on the `index.lock` file instead of the `index` file. Technically, we could teach `run_add_i()` (and `run_add_p()`) to look specifically at that environment variable, but the entire idea of passing in a parameter of type `struct repository *` is to allow working on multiple repositories (and their index files) independently. So let's instead override the `index_file` field of that structure temporarily. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When `interactive.singlekey = true`, we react immediately to keystrokes, even to Escape sequences (e.g. when pressing a cursor key). The problem with Escape sequences is that we do not really know when they are done, and as a heuristic we poll standard input for half a second to make sure that we got all of it. While waiting half a second is not asking for a whole lot, it can become quite annoying over time, therefore with this patch, we read the terminal capabilities (if available) and extract known Escape sequences from there, then stop polling immediately when we detected that the user pressed a key that generated such a known sequence. This recapitulates the remaining part of b5cc003 (add -i: ignore terminal escape sequences, 2011-05-17). Note: We do *not* query the terminal capabilities directly. That would either require a lot of platform-specific code, or it would require linking to a library such as ncurses. Linking to a library in the built-ins is something we try very hard to avoid (we even kicked the libcurl dependency to a non-built-in remote helper, just to shave off a tiny fraction of a second from Git's startup time). And the platform-specific code would be a maintenance nightmare. Even worse: in Git for Windows' case, we would need to query MSYS2 pseudo terminals, which `git.exe` simply cannot do (because it is intentionally *not* an MSYS2 program). To address this, we simply spawn `infocmp -L -1` and parse its output (which works even in Git for Windows, because that helper is included in the end-user facing installations). This is done only once, as in the Perl version, but it is done only when the first Escape sequence is encountered, not upon startup of `git add -i`; This saves on startup time, yet makes reacting to the first Escape sequence slightly more sluggish. But it allows us to keep the terminal-related code encapsulated in the `compat/terminal.c` file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The scripted version of `git stash` called directly into the Perl script `git-add--interactive.perl`, and this was faithfully converted to C. However, we have a much better way to do this now: call `git add --patch=<mode>`, which incidentally also respects the config setting `add.interactive.useBuiltin`. Let's do this. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This job runs the test suite twice, once in regular mode, and once with a whole slew of `GIT_TEST_*` variables set. Now that the built-in version of `git add --interactive` is feature-complete, let's also throw `GIT_TEST_MULTI_PACK_INDEX` into that fray. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The first part of the long journey to a fully built-in `git add -i`. It reflects the part that was submitted a couple of times (see gitgitgadget#103) during the Outreachy project by Slavica Đukić that continued the journey based on an initial patch series by Daniel Ferreira. This part only implements the `status` and the `help` part, like Slavica's last iteration did, in the interest of making the review remotely more reviewable. I fear that this attempt of making it a bit more reviewable is pretty futile, as so many things changed. So I will ask the reviewers for forgiveness: please be kind, and give this sort of a fresh review. I threw in a couple of major changes on top of that iteration, though: - The original plan was to add a helper (`git add--helper`) that takes over more and more responsibility from the Perl script over the course of the conversion. This plan is no longer in effect, as I encountered a serious problem with that: the MSYS2 runtime used by the Perl interpreter which Git for Windows employs to run `git add -i` has a curious bug (that is safely outside the purview of this here patch series) where it fails to read from standard input after it spawned a non-MSYS2 program that reads from standard input. To keep my `git add -i` in a working state, I therefore adopted a different strategy: Just like `git difftool` was converted by starting with a built-in that did nothing but handing off to the scripted version, guarded by the (opt-in) `difftool.useBuiltin` config setting, I start this patch series by a built-in `add -i` that does nothing else but state that it is not implemented yet, guarded by the (opt-in) `add.interactive.useBuiltin` config setting. In contrast to the `git difftool` situation, it is quite a bit easier here, as we do not even have to rename the script to `git-legacy-add--interactive.perl`: the `add--interactive` command is an implementation detail that users are not even supposed to know about. Therefore, we can implement that road fork between the built-in and the scripted version in `builtin/add.c`, i.e. in the user-facing `git add` command. This will also naturally help with the transition to a fully built-in `git add -i`/`git add -p`, as we saw with the built-in `git rebase` how important it is for end users to have an escape hatch (and for that reason, tried our best to provide the same with the built-in `git stash`). - The `help` command was actually not hooked up in `git add -i`, but was only available as a special option of the `git add--helper` command. As that command no longer exists, I kind of *had* to implement some way to let the built-in `git add -i` show the help text. - The main loop of `git add -i` (i.e. the thing that lets you choose `status` or `help`) is now implemented (but only lists `status` and `help`, of course), as it makes use of that feature that took the main chunk of the Outreachy project: the function to determine unique prefixes of a list of strings. - Speaking of the unique prefixes: the functionality to determine those is now encapsulated in the `prefix-map.c` file, and I also added a regression test. - Speaking of the tests: I also implemented support for the environment variable `GIT_TEST_ADD_I_USE_BUILTIN`: by setting it, the test suite can be forced to use the built-in, or the Perl script, version of `git add -i`. Needless to say: by the end of this patch series, running the test suite with `GIT_TEST_ADD_I_USE_BUILTIN=true` will still result in a ton of test failures due to not-yet-implemented commands, but it will also demonstrate what *already* works. - Since the main loop starts not only by showing the status, but refreshes the index before that, I added that, and I actually refactored that code into a new function (`repo_refresh_and_write_index()`), as it will be used a couple of times by the end of the complete conversion of `git add -i` into a built-in command. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 7e9e048 (stash -p: demonstrate failure of split with mixed y/n, 2015-04-16), a regression test for a known breakage that was added to the test script `t3904-stash-patch.sh` that demonstrated that splitting a hunk and trying to stash only part of that split hunk fails (but shouldn't). As expected, it still fails, but for the wrong reason: once the bug is fixed, we would expect stderr to show nothing, yet the regression test expects stderr to show something. Let's fix that by telling that regression test case to expect nothing to be printed to stderr. While at it, also drop the obvious left-over from debugging where the regression test did not mind `git stash -p` to return a non-zero exit status. Of course, the regression test still fails, but this time for the correct reason. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This patch series implements the rest of the commands in `git add -i`'s main loop: `update`, `revert`, `add_untracked`, `patch`, `diff`, and `quit`. Apart from `quit`, these commands are all very similar in that they first build a list of files, display it, let the user choose which ones to act on, and then perform the action. Note that the `patch` command is not actually converted to C, not completely at least: the built-in version simply hands off to `git add--interactive` after letting the user select which files to act on. The reason for this omission is practicality. Out of the 1,800+ lines of `git-add--interactive.perl`, over a thousand deal *just* with the `git add -p` part. I did convert that functionality already (to be contributed in a separate patch series), discovering that there is so little overlap between the `git add --patch` part and the rest of `git add --interactive` that I could put the former into a totally different file: `add-patch.c`. Just a teaser ;-) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When trying to stash part of the worktree changes by splitting a hunk and then only partially accepting the split bits and pieces, the user is presented with a rather cryptic error: error: patch failed: <file>:<line> error: test: patch does not apply Cannot remove worktree changes and the command would fail to stash the desired parts of the worktree changes (even if the `stash` ref was actually updated correctly). We even have a test case demonstrating that failure, carrying it for four years already. The explanation: when splitting a hunk, the changed lines are no longer separated by more than 3 lines (which is the amount of context lines Git's diffs use by default), but less than that. So when staging only part of the diff hunk for stashing, the resulting diff that we want to apply to the worktree in reverse will contain those changes to be dropped surrounded by three context lines, but since the diff is relative to HEAD rather than to the worktree, these context lines will not match. Example time. Let's assume that the file README contains these lines: We the people and the worktree added some lines so that it contains these lines instead: We are the kind people and the user tries to stash the line containing "are", then the command will internally stage this line to a temporary index file and try to revert the diff between HEAD and that index file. The diff hunk that `git stash` tries to revert will look somewhat like this: @@ -1776,3 +1776,4 We +are the people It is obvious, now, that the trailing context lines overlap with the part of the original diff hunk that the user did *not* want to stash. Keeping in mind that context lines in diffs serve the primary purpose of finding the exact location when the diff does not apply precisely (but when the exact line number in the file to be patched differs from the line number indicated in the diff), we work around this by reducing the amount of context lines: the diff was just generated. Note: this is not a *full* fix for the issue. Just as demonstrated in t3701's 'add -p works with pathological context lines' test case, there are ambiguities in the diff format. It is very rare in practice, of course, to encounter such repeated lines. The full solution for such cases would be to replace the approach of generating a diff from the stash and then applying it in reverse by emulating `git revert` (i.e. doing a 3-way merge). However, in `git stash -p` it would not apply to `HEAD` but instead to the worktree, which makes this non-trivial to implement as long as we also maintain a scripted version of `add -i`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
While re-implementing `git add -i` and `git add -p` in C, I tried to make sure that there is test coverage for all of the features I convert from Perl to C, to give me some confidence in the correctness from running the test suite both with `GIT_TEST_ADD_I_USE_BUILTIN=true` and with `GIT_TEST_ADD_I_USE_BUILTIN=false`. However, I discovered that there are a couple of gaps. This patch series intends to close them. The first patch might actually not be considered a gap by some: it basically removes the need for the `TTY` prerequisite in the `git add -i` tests to verify that the output is colored all right. This change is rather crucial for me, though: on Windows, where the conversion to a built-in shows the most obvious benefits, there are no pseudo terminals (yet), therefore `git.exe` cannot work with them (even if the MSYS2 Perl interpreter used by Git for Windows knows about some sort of pty emulation). And I *really* wanted to make sure that the colors work on Windows, as I personally get a lot out of those color cues. The patch series ends by addressing two issues that are not exactly covering testing gaps: - While adding a test case, I noticed that `git add -p` exited with *success* when it could not even generate a diff. This is so obviously wrong that I had to fix it right away (I noticed, actually, because my in-progress built-in `git add -p` failed, and the Perl version did not), and I used the same test case to verify that this is fixed once and for all. - While working on covering those test gaps, I noticed a problem in an early version of the built-in version of `git add -p` where the `git apply --allow-overlap` mode failed to work properly, for little reason, and I fixed it real quick. It would seem that the `--allow-overlap` function is not only purposefully under-documented, but also purposefully under-tested, probably to discourage its use. I do not quite understand what I perceive to be Junio's aversion to that option, but I did not feel like I should put up a battle here, so I did not accompany this fix with a new test script. In the end, the built-in version of `git add -p` does not use the `--allow-overlap` function at all, anyway. Which should make everybody a lot happier. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Out of all the patch series on the journey to provide `git add --interactive` and `git add --patch` in a built-in versions, this is the big one, as can be expected from the fact that the `git add --patch` functionality makes up over half of the 1,800+ lines of `git-add--interactive.perl`. The two patches that stick out are of course the ones to implement hunk splitting and hunk editing: these operations are fundamentally more complicated, and less obvious, than the rest of the operations. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
At this stage on the journey to a fully built-in `git add`, we already have everything we need, including the `--interactive` and `--patch` options, as long as the `add.interactive.useBuiltin` setting is set to `true` (kind of a "turned off feature flag", which it will be for a while, until we get confident enough that the built-in version does the job, and retire the Perl script). However, the internal `add--interactive` helper is also used to back the `--patch` option of `git stash`, `git reset` and `git checkout`. This patch series brings them "online". Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the final leg of the journey to a fully built-in `git add`: the `git add -i` and `git add -p` modes were re-implemented in C, but they lacked support for a couple of config settings. The one that sticks out most is the `interactive.singleKey` setting: it was not only particularly hard to get to work, especially on Windows. It is also the setting that seems to be incomplete already in the Perl version: while the name suggests that it applies to the main loop of `git add --interactive`, or to the file selections in that command, it does not. Only the `git add --patch` mode respects that setting. As it is outside the purpose of the conversion of `git-add--interactive.perl` to C, we will leave that loose end for some future date. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch fixes a corner case that is amazingly common in this developer's workflow: in a `git stash -p`, splitting a hunk and stashing only part of it runs into a (known) bug where the partial hunk cannot be applied in reverse. It is one of those "good enough" fixes, not a full fix, though, as the full fix would require a 3-way merge between `stash^` and the *worktree* (not `HEAD`), with `stash` as merge base (i.e. a `git revert`, but on top of the current worktree). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Between the libgit2 and the Git for Windows project, there has been a discussion how we could share Git configuration to avoid duplication (or worse: skew). Earlier, libgit2 was nice enough to just re-use Git for Windows' C:\Program Files (x86)\Git\etc\gitconfig but with the upcoming Git for Windows 2.x, there would be more paths to search, as we will have 64-bit and 32-bit versions, and the corresponding config files will be in %PROGRAMFILES%\Git\mingw64\etc and ...\mingw32\etc, respectively. Worse: there are portable Git for Windows versions out there which live in totally unrelated directories, still. Therefore we came to a consensus to use `%PROGRAMDATA%\Git\config` as the location for shared Git settings that are of wider interest than just Git for Windows. Of course, the configuration in `%PROGRAMDATA%\Git\config` has the widest reach, therefore it must take the lowest precedence, i.e. Git for Windows can still override settings in its `etc/gitconfig` file. Helped-by: Andreas Heiduk <asheiduk@gmail.com> 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>
To avoid running into command line limitations, some of Git's commands support the `--stdin` option. Let's use exactly this option in the three rev-list/log invocations in gitk that would otherwise possibly run the danger of trying to invoke a too-long command line. While it is easy to redirect either stdin or stdout in Tcl/Tk scripts, what we need here is both. We need to capture the output, yet we also need to pipe in the revs/files arguments via stdin (because stdin does not have any limit, unlike the command line). To help this, we use the neat Tcl feature where you can capture stdout and at the same time feed a fixed string as stdin to the spawned process. One non-obvious aspect about this change is that the `--stdin` option allows to specify revs, the double-dash, and files, but *no* other options such as `--not`. This is addressed by prefixing the "negative" revs with `^` explicitly rather than relying on the `--not` option (thanks for coming up with that idea, Max!). This fixes #1987 Analysis-and-initial-patch-by: Max Kirillov <max@max630.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When grepping through the output of a command in the test suite, there is always a chance that something goes wrong, in which case there would not be anything useful to debug. Let's redirect the output into a file instead, and grep that file, so that the log can be inspected easily if the grep fails. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It seems to be not exactly rare on Windows to install NTFS junction points (the equivalent of "bind mounts" on Linux/Unix) in worktrees, e.g. to map some development tools into a subdirectory. In such a scenario, it is pretty horrible if `git clean -dfx` traverses into the mapped directory and starts to "clean up". Let's just not do that. Let's make sure before we traverse into a directory that it is not a mount point (or junction). This addresses #607 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
config.mak.uname: PCRE1 cleanup
Fixes #2293 Signed-off-by: Nico Rieck <nico.rieck@gmail.com>
rebase-merges: improve --rebase-merges label generation
We recently hardened Git for Windows by ignoring `C:\ProgramData\Git\config` files unless they are owned by the system account, by the administrators group, or by the account under which Git is running. Turns out that there are situations when that config file is owned by _an_ administrator, not by the entire administrators group, and that still is okay. This can happen very easily e.g. in Docker Containers. Let's add a fall back when the owner is none of the three currently expected ones, enumerating the members of the administrators group and comparing them to the file's owner. If a match is found, the owner is not dubious. Enumerating groups' members on Windows is not exactly a cheap operation, and it requires linking to the `netapi32.dll`. Since this is rarely needed, and since this is done at most a handful of times during any Git process' life cycle, it is okay that it is a bit expensive. To avoid the startup cost of linking to yet another DLL, we do this lazily instead: that way, the vast majority of Git for Windows' users will not feel any impact by this patch. This fixes #2304. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
gitk: Escape file paths before piping to git log
…ific-administrator Do not complain if `C:\ProgramData\Git\config` is owned by a specific administrator
The vcpkg_install batch file depends on the availability of a working Git on the CMD path. This may not be present if the user has selected the 'bash only' option during Git-for-Windows install. Detect and tell the user about their lack of a working Git in the CMD window. Fixes #2348. A separate PR git-for-windows/build-extra#258 now highlights the recommended path setting during install. Signed-off-by: Philip Oakley <philipoakley@iee.email>
The vcpkg downloads may not succeed. Warn careful readers of the time out. A simple retry will usually resolve the issue. Signed-off-by: Philip Oakley <philipoakley@iee.email> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Vcpkg Install: detect lack of working Git, and note possible vcpkg time outs
Required by `ew/hashmap`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Needed by `ds/include-exclude`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Thomas Gummerer provided an alternative implementation of `repo_refresh_and_write_index()`. Let's use it. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Required by tg/stash-refresh-index. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…y in C Needed by `tg/stash-refresh-index`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Made necessary by `ew/hashmap`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…rings This is needed to accommodate for stricter checking of the `hashmap_*()` function family. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…tate The `orig_index` moved into the field `priv`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…tions Made necessary by `ew/hashmap`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Required by `ew/hashmap`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Made necessary by `ew/hashmap`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is required by `kt/add-i-progress`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is required by `kt/add-i-progress`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is required by `kt/add-i-progress`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…y in C This is required by `kt/add-i-progress`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
…y in C Needed by `tg/stash-refresh-index`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
... falling back to the old one. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
This does not appear to be a sensible merge. Maybe you accidentally requested it. If not, maybe describe what it was you were trying to do? The The |
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.
Thanks for taking the time to contribute to Git!
Those seeking to contribute to the Git for Windows fork should see
http://gitforwindows.org/#contribute on how to contribute Windows specific
enhancements.
If your contribution is for the core Git functions and documentation
please be aware that the Git community does not use the github.com issues
or pull request mechanism for their contributions.
Instead, we use the Git mailing list (git@vger.kernel.org) for code and
documenatation submissions, code reviews, and bug reports. The
mailing list is plain text only (anything with HTML is sent directly
to the spam folder).
Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.
Please read the "guidelines for contributing" linked above!