Just like with other Git commands, this option makes it read the paths
from the standard input. It comes in handy when resetting many, many
paths at once and wildcards are not an option (e.g. when the paths are
generated by a tool).
Note: we first parse the entire list and perform the actual reset action
only in a second phase. Not only does this make things simpler, it also
helps performance, as do_diff_cache() traverses the index and the
(sorted) pathspecs in simultaneously to avoid unnecessary lookups.
This feature is marked experimental because it is still under review in
the upstream Git project.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is a "dummy" rebase, because we already rebased to that tag.
So why rebase, then? For multiple reasons:
1. to pull in `origin/master`'s commit history (without actually taking
its changes, because we already forward-ported the
dont-spawn-gzip-in-archive patches to `rebase-to-v2.21.0`.
2. to reorder some built-in stash related patches into the correct spot.
3. to move the dont-spawn-gzip-in-archive patches into the
ready-for-upstream branch thicket.
This commit starts the rebase of 948d034ce3 to 1c668b7b88be
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We accepted a Pull Request into `master`, but the main development
happens on the topic branch `rebase-to-v2.21.0` right now, in
preparation for the final v2.21.0 in a couple of days.
So after we forward-ported the changes in a6567c7b2c (Merge pull
request #2077 from r1walz/gzip-cmd-404, 2019-02-20), it is now time to
pull in the commit history of origin/master in a fake merge (i.e. with
`-s ours`), to make `master` fast-forward to `rebase-to-v2.21.0` again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 45c1389c31 (stash: convert apply to builtin, 2018-12-20), we
introduced code that is the equivalent of `git write-tree && git
read-tree`. But the original shell script only called `git write-tree`
(because the read-tree would obviously be a no-op). So let's skip the
reset_tree() call that is the equivalent that that `git read-tree`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In 9a67cb4f1f (stash: convert push to builtin, 2018-12-20), we started
to call `git apply -R --index` and `git reset --hard`, but held onto the
now-stale index in memory. Let's discard it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
As we already link to `zlib` library, we can perform the
compression without even requiring gzip on the host
machine
We modify write_tar_filter_archive() function in archive-tar.c
to handle the compression when `gzip -cn` is requested
Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com>
MinGit for Windows comes without `gzip` bundled inside,
git-archive uses `gzip -cn` to compress tar files but
for this to work, gzip needs to be present on the host
system, which sometimes is not the case
In the next commit, we will change the gzip compression
so that we no longer spawn `gzip` but let zlib perform
the compression in the same process
In preparation for this, we consolidate all the block
writes into a single function
Closes: #1970
Signed-off-by: Rohit Ashiwal <rohit.ashiwal265@gmail.com>
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>
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>
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>
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>
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>
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>
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>
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 https://github.com/git-for-windows/git/issues/1218
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>
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.
