This trick was performed by rebasing the builtin-stash-rebase branch
thicket via `git rebase -kir v2.19.0-rc2`, replacing all branches that
made it into `pu` by their current versions (and also the builtin-stash
by the newest iteration as of ungps/git), and then calling these
commands:
# save current tip
tip=$(git rev-parse HEAD)
# revert previous merge
git reset --hard git-for-windows/master^0
git revert -n -m 1 HEAD
git commit --squash HEAD -s -m "Let's drop this"
# now perform the 3-way merge with v2.19.0-rc2 as base
git merge-recursive v2.19.0-rc2 -- HEAD $tip
git merge --ff-only \
$(git commit-tree -p HEAD -p $tip -m "Merge" \
$(git write-tree))
git commit -c HEAD^^ --amend -s
The merge-recursive dance is necessary because of the merging-rebases:
the fake merges with which these start are mistaken by `git merge` to
mean that the branches were already merged, when the fake merges undid
the corresponding changes.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Update the config documentation to note the value `2` as an acceptable
value for the protocol.version config.
Signed-off-by: Brandon Williams <bmwill@google.com>
Signed-off-by: Josh Steadmon <steadmon@google.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
A couple of fixes that should be squashed during the next merging
rebase of Git for Windows.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The upcoming Git for Windows v2.19.0 wants to ship with the builtin
versions of stash, rebase and rebase -i. The reason: these are just *so
much faster*: t3400 and t3404 run about 60-70 percent faster, and t3903
even more than 80% faster.
However, these are still all pretty fresh, still being reviewed and
iterated on the Git mailing list.
So let's try to give users a way to test these (or to boldly use them
for their mission-critical tasks, as this here developer plans on
doing), but stay with the safe option by default: use the scripted
versions (which might be slow, but they are well tested).
Signed-off-by: Johannes Schindelin <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>
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 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 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 *would* be a fixup commit, except that we want to avoid rewriting
commits that we merged from upstream's `pu` branch. Instead, we want to
send a new iteration, and then re-merge the new iteration once it made
it into the `pu` branch.
Signed-off-by: Johannes Schindelin <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>
This final patch flips the switch and makes the builtin rebase the
default. The old, Unix shell scripted version can still be called via
git -c rebase.useBuiltin=false rebase [...]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch first merges the builtin interactive rebase, and then
teaches the builtin rebase to hand off interactive rebases to the
builtin backend correctly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This fifth batch of builtin rebase patches concludes the conversion: the
builtin rebase is now feature-complete.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This wave of built rebase patches implements the remaining rebase
options in the builtin rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This set of patches implements the actions (such as --continue, --skip,
etc) in the builtin rebase.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the first batch of the patches that turn `git rebase` into
a builtin.
This not only helps performance on Windows, but *especially* makes
things more robust, as no MSYS2 Bash will be required to run this
command any longer.
Signed-off-by: Johannes Schindelin <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>
Completely convert the pathname expoted in the %msvc_bin_dir_msys%
variable to MSYS format with forward slashes rather than a mixture
of forward and back slashes.
This solves an obscure problem observed by some developers:
[...]
http-push.c
CC remote-curl.o
remote-curl.c
* new script parameters
GEN git-instaweb
sed: -e expression #7, char 155: invalid reference \2 on `s' command's RHS
make: *** [Makefile:2023: git-instaweb] Error 1
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Add new condition to invoke vcpkg_install.bat: it's not enough to check
the presence of folder vcpkg. We need to check the presence of some
header files because this is one of the main goals of this script.
Previous build attempt could be aborted, so the folder will exist but
the project will not be built properly.
Signed-off-by: Olga Telezhnaia <olyatelezhnaya@gmail.com>
This is part two of the Ctrl+C story, where part one is
https://github.com/git-for-windows/MSYS2-packages/commit/f4fda0f30aa.
Part one took care of extending the signal handling in the MSYS2 runtime
such that non-MSYS2 processes "receive" a SIGINT by injecting a remote
thread that runs kernel32!CtrlRoutine as if GenerateConsoleCtrlHandler()
had been called (but in contrast to the latter, only one process is
targeted at a time, not every process attached to the same Console) into
the process that needs to be interrupted as well as into all of the
spawned child processes.
Part two now takes care of removing the misguided "kill all spawned
children" atexit() handler, and it also installs a ConsoleCtrl handler
to run Git's SIGINT handlers, such as the one waiting for the pager to
exit.
Signed-off-by: Johannes Schindelin <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>
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>
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>
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>
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>
When working in the root directory of a file share (this is only
possible in Git Bash and Powershell, but not in CMD), the current
directory is reported without a trailing slash.
This is different from Unix and standard Windows directories: both / and
C:\ are reported with a trailing slash as current directories.
If a Git worktree is located there, Git is not quite prepared for that:
while it does manage to find the .git directory/file, it returns as
length of the top-level directory's path *one more* than the length of
the current directory, and setup_git_directory_gently() would then
return an undefined string as prefix.
In practice, this undefined string usually points to NUL bytes, and does
not cause much harm. Under rare circumstances that are really involved
to reproduce (and not reliably so), the reported prefix could be a
suffix string of Git's exec path, though.
A careful analysis determined that this bug is unlikely to be
exploitable, therefore we mark this as a regular bug fix.
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.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
This fixes the issue identified in
https://github.com/git-for-windows/git/issues/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>
The current CONTRIBUTING.md file is actually a code of conduct. This is
a valuable document, but is misnamed. A following patch will replace
CONTRIBUTING.md with a guide to contributing to Git using a Windows machine.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
We ran out of GUIDs in the script generating Visual Studio project
files. This topic branch fixes that issue once and for all, by
generating the GUIDs.
For extra goodness, we now generate GUIDs that are not random, but are
generated from the SHA-256 checksums of the target file of the project.
That way, the project<->GUID mapping is stable.
This fixes https://github.com/git-for-windows/git/issues/1507
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is retry of #1419.
I added flush_fscache macro to flush cached stats after disk writing
with tests for regression reported in #1438 and #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>
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>
