The CI builds are failing for Mac OS X due to a change in the
location of the perforce cask. The command outputs the following
error:
+ brew install caskroom/cask/perforce
Error: caskroom/cask was moved. Tap homebrew/cask-cask instead.
Preface the "brew install caskroom/cask/perforce" with the old
way of installing perforce, and only try this method if the
"brew install perforce" fails.
The existing way to use caskroom was added in 672f51cb (travis-ci:
fix Perforce install on macOS, 2017-01-22) and the justification
is that the "brew install perforce" can fail due to a hash
mis-match. The mismatch is due to the official Perforce distro
updating the published binaries without updating the version
string. CI servers are typically fresh virtual machines, so that
issue should not arise in automated builds.
Even if a build server is re-used and hits the hash mis-match,
it will fall back to the "new" mechanism which is currently
failing, but may be fixed independently of this change.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
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>
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 https://github.com/git-for-windows/build-extra/pull/258
now highlights the recommended path setting during install.
Signed-off-by: Philip Oakley <philipoakley@iee.email>
Fix a few more unclear/incorrect phrasings (while the perfect is the
enemy of the good, the vague and the not-quite-right are the enemy of
the good-enough).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As suggested in
https://github.com/git-for-windows/git/pull/2303#issuecomment-524351036:
Also mention the release candidate and snapshot version numberings, e.g.
that the final release's installer will claim that the release candidates
are newer than the proper release.
And also note the existence of the snapshots; This may encourage others
to participate in the 'development'.
Signed-off-by: Philip Oakley <philipoakley@iee.email>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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 https://github.com/git-for-windows/git/issues/2304.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Let's refactor the `validate_system_file_ownership()` a bit, not only to
clarify what is done, but also to prepare for maybe adding a slighty
more expensive check: it is possible that the file
`C:\ProgramData\Git\config` is owned by the local administrator (who has
a different SID than the `Administrators` group).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `label` todo command in interactive rebases creates temporary refs
in the `refs/rewritten/` namespace. These refs are stored as loose refs,
i.e. as files in `.git/refs/rewritten/`, therefore they have to conform
with file name limitations on the current filesystem.
This poses a problem in particular on NTFS/FAT, where e.g. the colon
character is not a valid part of a file name.
Let's safeguard against this by replacing not only white-space
characters by dashes, but all non-alpha-numeric ones.
However, we exempt non-ASCII UTF-8 characters from that, as it should be
quite possible to reflect branch names such as `↯↯↯` in refs/file names.
Signed-off-by: Matthew Rogers <mattr94@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the recommended way on GitHub to describe policies revolving around
security issues and about supported versions.
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>
We already avoid traversing NTFS junction points in `git clean -dfx`.
With this topic branch, we do that when the FSCache is enabled, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When updating the skip-worktree bits in the index to align with new
values in a sparse-checkout file, Git scans the entire working
directory with lstat() calls. In a sparse-checkout, many of these
lstat() calls are for paths that do not exist.
Enable the fscache feature during this scan.
In a local test of a repo with ~2.2 million paths, updating the index
with `git read-tree -m -u HEAD` with a sparse-checkout file containing
only `/.gitattributes` improved from 2-3 minutes to 15-20 seconds.
More work could be done to stop running lstat() calls when recursing
into directories that are known to not exist.
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>
This topic branch allows `add -p` and `add -i` with a large number of
files. It is kind of a hack that was never really meant to be
upstreamed. Let's see if we can do better in the built-in `add -p`.
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>
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>
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.
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>
