From: Johannes Schindelin
The scripted version (partially) heeded the `GIT_REFLOG_ACTION` and when
we converted to a built-in, this regressed.
Fix that, and add a regression test, both with `GIT_REFLOG_ACTION` set
and unset.
Note: the reflog message for "rebase finished" did *not* heed
It has been reported on the Debian bug tracker
[https://bugs.debian.org/914695] that the built-in rebase regresses on the
scripted version, and later details emerged that this has something to do
with the reflog messages: they were different with the built-in rebase than
with the scripted one.
We're really entering obscure territory here, I would say.
To trigger the bug, two things have to come together: the user must have
asked for a diffstat afterwards, and the commits need to have been rebased
onto a completely unrelated commit history (i.e. there must exist no merge
base between
From: Johannes Schindelin
When rebasing to a commit history that has no common commits with the
current branch, there is no merge base. In diffstat mode, this means
that we cannot compare to the merge base, but we have to compare to the
empty tree instead.
Also, if running in verbose diffstat
From: Johannes Schindelin
When rebasing to a commit history that has no common commits with the
current branch, there is no merge base. The scripted version of the `git
rebase` command was not prepared for that and spewed out
fatal: ambiguous argument '': unknown revision or path not in
We're really entering obscure territory here, I would say.
To trigger the bug, two things have to come together: the user must have
asked for a diffstat afterwards, and the commits need to have been rebased
onto a completely unrelated commit history (i.e. there must exist no merge
base between
The topic ot/ref-filter-object-info broke the Windows build since it entered
pu, and as a consequence we have no test coverage of the other topics in pu.
Sadly, this topic now advanced to next. Junio, I would like to ask you to
merge this fix down to next and to advance to master together with
From: Johannes Schindelin
The `%lld` format is supported on Linux and macOS, but not on Windows.
This issue has been reported ten days ago (Message-ID:
nycvar.qro.7.76.6.1811121300520...@tvgsbejvaqbjf.bet), but the
corresponding topic still advanced to `next` in the meantime, breaking
the
This is a backport, really, to accommodate a new regression test that was
introduced when the built-in rebase learned to validate the -C and
--whitespace= arguments early.
Johannes Schindelin (1):
legacy-rebase: backport -C and --whitespace= checks
git-legacy-rebase.sh | 8
1 file
From: Johannes Schindelin
Since 04519d720114 (rebase: validate -C and --whitespace=
parameters early, 2018-11-14), the built-in rebase validates the -C and
--whitespace arguments early. As this commit also introduced a
regression test for this, and as a later commit introduced the
From: Johannes Schindelin
This was a simple copy/paste error, and an obvious one at that: if we
cannot fill the tree descriptor, we should show an error message about
*that* tree, not another one.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 3 ++-
1 file changed, 2
A quick fix for a recent topic. Not overly critical, but I would deem this
v2.20.0-rc1 material.
Johannes Schindelin (1):
rebase: warn about the correct tree's OID
builtin/rebase.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
base-commit: bb75be6cb916297f271c846f2f9caa3daaaec718
It is a pretty neat thing that the bulky MSDN documentation has been
replaced by something a lot more open, something that can be updated via
Pull Requests on GitHub. Let's link to this new documentation instead of the
obsolete one.
I know, it is really close to the code freeze leading up to Git
From: Johannes Schindelin
The MSDN documentation has been superseded by Microsoft Docs (which is
backed by a repository on GitHub containing many, many files in Markdown
format).
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Johannes Schindelin
It really makes very, very little sense to use a different git
executable than the one the caller indicated via setting the environment
variable GIT_TEST_INSTALLED.
Signed-off-by: Johannes Schindelin
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2
From: Johannes Schindelin
We really only need the test helpers to be built in the worktree in that
case, but that is not what we test for.
On the other hand it is a perfect opportunity to verify that
`GIT_TEST_INSTALLED` points to a working Git.
So let's test the appropriate Git executable.
From: Johannes Schindelin
It makes very, very little sense to test the built git-sh-i18n when the
user asked specifically to test another one.
Signed-off-by: Johannes Schindelin
---
t/lib-gettext.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/lib-gettext.sh
From: Johannes Schindelin
On Windows, when we refer to `/an/absolute/path/to/git`, it magically
resolves `git.exe` at that location. Except if something of the name
`git` exists next to that `git.exe`. So if we call `$BUILD_DIR/git`, it
will find `$BUILD_DIR/git.exe` *only* if there is not, say,
From: Johannes Schindelin
We really need to be able to find the test helpers... Really. This
change was forgotten when we moved the test helpers into t/helper/
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
By setting the GIT_TEST_INSTALLED variable to the path of an installed Git
executable, it is possible to run the test suite also on a specific
installed version (as opposed to a version built from scratch).
The only thing this needs that is unlikely to be installed is the test
helper(s).
From: Johannes Schindelin
It is a good idea to error out early upon seeing, say, `-Cbad`, rather
than starting the rebase only to have the `--am` backend complain later.
Let's do this.
The only options accepting parameters which we pass through to `git am`
(which may, or may not, forward them
From: Johannes Schindelin
Currently, we parse the options intended for `git am` as if we wanted to
handle them in `git rebase`, and then reconstruct them painstakingly to
define the `git_am_opt` variable.
However, there is a much better way (that I was unaware of, at the time
when I mentored
Phillip Wood reported a problem where the built-in rebase did not understand
options like -C1, i.e. it did not expect the option argument.
While investigating how to address this best, I stumbled upon
OPT_PASSTHRU_ARGV (which I was so far happily unaware of).
Instead of just fixing the -C bug,
And yet another patch coming through Git for Windows...
Change since v1:
* Using a better oneline now.
Gaël Lhez (1):
bundle: cleanup lock files on error
bundle.c| 7 ---
t/t5607-clone-bundle.sh | 4
2 files changed, 8 insertions(+), 3 deletions(-)
base-commit:
Back when bw/config-h was developed (and backported to Git for Windows), I
came up with a patch to use git_dir if commondir is NULL, and contributed
that as v1 of this patch. However, it was deemed a bug if that happens, so
let's instead detect that condition and report it.
Change since v1:
*
From: Johannes Schindelin
This did happen at some stage, and was fixed relatively quickly. Make
sure that we detect very quickly, too, should that happen again.
Signed-off-by: Johannes Schindelin
---
config.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.c b/config.c
index
And yet another patch from Git for Windows' cache of treasures.
It was challenging to emulate the functions related to pthread_cond_t as
long as we tried to maintain support for Windows XP, which has nothing close
to that feature. Now that we require Windows Vista or later, we can make use
of the
And yet another patch coming through Git for Windows...
Gaël Lhez (1):
bundle: refuse to create empty bundle
bundle.c| 7 ---
t/t5607-clone-bundle.sh | 4
2 files changed, 8 insertions(+), 3 deletions(-)
base-commit: 8858448bb49332d353febc078ce4a3abcc962efe
Back when bw/config-h was developed (and backported to Git for Windows), I
came up with this patch. It seems to not be strictly necessary, but I like
the safety of falling back to the Git directory when no common directory is
configured (for whatever reason).
Johannes Schindelin (1):
From: Johannes Schindelin
Just some defensive programming.
Signed-off-by: Johannes Schindelin
---
config.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/config.c b/config.c
index 4051e38823..279d0d7077 100644
--- a/config.c
+++ b/config.c
@@ -1676,6 +1676,8 @@ static int
This is another tidbit from the stash of Git for Windows' patches: it avoids
loading the function address of CreateHardLink() at runtime. This was done
in case we were running on a Windows version that does not support that
function, but we no longer support any of these Windows versions.
From: Johannes Schindelin
The function `CreateHardLink()` is available in all supported Windows
versions (even since Windows XP), so there is no more need to resolve it
at runtime.
Helped-by: Max Kirillov
Signed-off-by: Johannes Schindelin
---
compat/mingw.c | 14 +-
1 file
Phillip Wood reported a problem where the built-in rebase did not understand
options like -C1, i.e. it did not expect the option argument.
While investigating how to address this best, I stumbled upon
OPT_PASSTHRU_ARGV (which I was so far happily unaware of).
Instead of just fixing the -C bug,
From: Johannes Schindelin
Currently, we parse the options intended for `git am` as if we wanted to
handle them in `git rebase`, and then reconstruct them painstakingly to
define the `git_am_opt` variable.
However, there is a much better way (that I was unaware of, at the time
when I mentored
From: Johannes Schindelin
When we detect that a `merge` can be skipped because the merged commit
is already an ancestor of HEAD, we do not need to commit, therefore
writing the MERGE_HEAD file is useless.
It is actually worse than useless: a subsequent `git commit` will pick
it up and think
From: Johannes Schindelin
Every once in a while, the interactive rebase makes sure that no stale
files are lying around. These days, we need to include MERGE_HEAD into
that set of files, as the `merge` command will generate them.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 2 ++
1
From: Johannes Schindelin
Since `git rebase -r` was introduced, that is possible. But our
machinery did not think that possible, and failed to say anything about
the rebase in progress when in the middle of a merge.
Let's work around that in the minimal fashion.
Signed-off-by: Johannes
From: Johannes Schindelin
When calling `merge` on a branch that has already been merged, that
`merge` is skipped quietly, but currently a MERGE_HEAD file is being
left behind and will then be grabbed by the next `pick` (that did
not want to create a *merge* commit).
Demonstrate this.
From: Johannes Schindelin
The scripted version of the rebase used to execute `git reset --hard`
when skipping or aborting. When we ported this to C, we did update the
worktree and some reflogs, but we failed to imitate `git reset --hard`'s
behavior regarding files in .git/ such as MERGE_HEAD.
I noticed a couple of weeks ago that I had bogus merge commits after my
rebases, where the original commits had been regular commits.
This set me out on the adventure that is reflected in this patch series.
Of course, the thing I wanted to fix is demonstrated by 1/5 and fixed in
2/5. But while
From: Johannes Schindelin
When editing patches e.g. in `git add -e`, it is quite common that a
hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing.
This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does
not do anything, 2015-06-01) with the good intention
I use git add -e frequently. Often there are multiple hunks and I end up
deleting the + lines and converting the - lines to context lines, as I like
to stage massive changes in an incremental fashion (and commit those staged
changes incrementally, too).
Some time after I invented git add -e, this
From: Johannes Schindelin
We really only need the test helpers in that case, but that is not what
we test for. So let's skip the test for now when we know that we want to
test an installed Git.
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1
From: Johannes Schindelin
In the bin-wrappers/* scripts, we already take pains to use `git.exe`
rather than `git`, as this could pick up the wrong thing on Windows
(i.e. if there exists a `git` file or directory in the build directory).
Now we do the same in the tests' start-up code.
This also
From: Johannes Schindelin
It makes very, very little sense to test the built git-sh-i18n when the
user asked specifically to test another one.
Signed-off-by: Johannes Schindelin
---
t/lib-gettext.sh | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/t/lib-gettext.sh
From: Johannes Schindelin
It really makes very, very little sense to use a different git
executable than the one the caller indicated via setting the environment
variable GIT_TEST_INSTALLED.
Signed-off-by: Johannes Schindelin
---
t/test-lib-functions.sh | 3 ++-
1 file changed, 2
From: Johannes Schindelin
We really need to be able to find the test helpers... Really. This
change was forgotten when we moved the test helpers into t/helper/
Signed-off-by: Johannes Schindelin
---
t/test-lib.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
By setting the GIT_TEST_INSTALLED variable to the path of an installed Git
executable, it is possible to run the test suite also on a specific
installed version (as opposed to a version built from scratch).
The only thing this needs that is unlikely to be installed is the test
helper(s).
From: Johannes Schindelin
Currently, we only accept the flag indicating whether the HEAD should be
detached not. In the next commit, we want to introduce another flag: to
toggle between emulating `reset --hard` vs `checkout -q`.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 9
In our tests with large repositories, we noticed a serious regression of the
performance of git rebase when using the built-in vs the shell script
version. It boils down to an incorrect conversion of a git checkout -q:
instead of using a twoway_merge as git checkout does, we used a oneway_merge
From: Johannes Schindelin
The same clean-up code is repeated quite a few times; Let's DRY up the
code some.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/builtin/rebase.c
From: Johannes Schindelin
When we converted a `git checkout -q $onto^0` call to use
`reset_head()`, we inadvertently incurred a change from a twoway_merge
to a oneway_merge, as if we wanted a `git reset --hard` instead.
This has performance ramifications under certain, though, as the
I noticed that there were a couple of duplicate entries in git shortlog -nse
v2.19.1.., and then continued a bit to remove the duplicate entries even for
v2.10.0..
Changes relative to v1:
* Fixed the commit message (it talked about the opposite commit range than
intended).
* Added a
From: Johannes Schindelin
This patch makes the output of `git shortlog -nse v2.10.0..master`
duplicate-free.
Signed-off-by: Johannes Schindelin
---
.mailmap | 13 +
1 file changed, 13 insertions(+)
diff --git a/.mailmap b/.mailmap
index bef3352b0d..eb7b5fc7b9 100644
---
In our tests with large repositories, we noticed a serious regression of the
performance of git rebase when using the built-in vs the shell script
version. It boils down to an incorrect conversion of a git checkout -q:
instead of using a twoway_merge as git checkout does, we used a oneway_merge
From: Johannes Schindelin
When we converted a `git checkout -q $onto^0` call to use
`reset_head()`, we inadvertently incurred a change from a twoway_merge
to a oneway_merge, as if we wanted a `git reset --hard` instead.
This has performance ramifications under certain, though, as the
From: Johannes Schindelin
The same clean-up code is repeated quite a few times; Let's DRY up the
code some.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index
From: Johannes Schindelin
This patch makes the output of `git shortlog -nse v2.10.0`
duplicate-free.
Signed-off-by: Johannes Schindelin
---
.mailmap | 13 +
1 file changed, 13 insertions(+)
diff --git a/.mailmap b/.mailmap
index bef3352b0d..1d8310073a 100644
--- a/.mailmap
+++
I noticed that there were a couple of duplicate entries in git shortlog -nse
v2.19.1.., and then continued a bit to remove the duplicate entries even for
v2.10.0..
Johannes Schindelin (1):
Update .mailmap
.mailmap | 13 +
1 file changed, 13 insertions(+)
base-commit:
It was reported that the new, shiny built-in git rebase has a bug where it
would detach the HEAD when it was not even necessary to detach it.
Keeping with my fine tradition to first demonstrate what is the actual
problem (and making it easy to verify my claim), this patch series first
introduces
From: Johannes Schindelin
An unnamed colleague of Ævar Arnfjörð Bjarmason reported a breakage
where a `pull --rebase` (which did not really need to do anything but
stash, see that nothing was changed, and apply the stash again) also
detached the HEAD.
This patch adds a minimal reproducer for
From: Johannes Schindelin
When we converted a `git reset --hard` call in the original Unix shell
script to built-in code, we asked to reset the worktree and the index
and explicitly *not* to detach the HEAD. By mistake, though, we still
did. Let's fix this.
Signed-off-by: Johannes Schindelin
This is a patch designed to help maintaining Git for Windows better: when
the same source code is "cross-compiled" for i686 as well as x86_64, we want
to rebuild the whole thing, including the resource file git.res.
Note: regular C files are re-compiled appropriately, as the default prefix
in Git
From: Johannes Schindelin
When git.rc is compiled into git.res, the result is actually dependent
on the architecture. That is, you cannot simply link a 32-bit git.res
into a 64-bit git.exe.
Therefore, to allow 32-bit and 64-bit builds in the same directory, we
let git.res depend on GIT-PREFIX
From: Johannes Schindelin
On Windows, an absolute POSIX path needs to be turned into a Windows
one.
Signed-off-by: Johannes Schindelin
---
path.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/path.c b/path.c
index 34f0f98349..a72abf0e1f 100644
--- a/path.c
+++ b/path.c
@@ -11,6
While this patch has been "in production" in Git for Windows for a good
while, this patch series is half meant as a request for comments.
The reason is this: something like this (make paths specified e.g. via
http.sslCAInfo relative to the runtime prefix) is potentially useful also in
the
This is yet another piece from the Git for Windows cake. It avoids a
wrap-around in the poll emulation on Windows that occurs every 49 days.
Steve Hoelzer (1):
poll: use GetTickCount64() to avoid wrap-around issues
compat/poll/poll.c | 10 +++---
1 file changed, 7 insertions(+), 3
From: Johannes Schindelin
The `--preserve-merges` mode of the `rebase` command is slated to be
deprecated soon, as the more powerful `--rebase-merges` mode is
available now, and the latter was designed with the express intent to
address the shortcomings of `--preserve-merges`' design (e.g. the
From: Johannes Schindelin
It is in general a good idea for regression test cases to be as
independent of each other as possible (with the one exception of an
initial `setup` test case, which is only a test case in Git's test suite
because it does not have a notion of a fixture or setup).
This
From: Johannes Schindelin
Originally, the `--preserve-merges` option of the `git rebase` command
piggy-backed on top of the `--interactive` feature. For that reason, the
early test cases were added to the very same test script that contains
the `git rebase -i` tests:
The --preserve-merges mode of the git rebase command is on its way out,
being superseded by the --rebase-merges mode. My plan is to contribute
patches to deprecate the former in favor of the latter before long.
In the meantime, it seems a bit pointless to keep running the git rebase -p
tests, in
This patch has been looong in the waiting (well over a year) for being sent
to the Git mailing list; it is a fixup for a change of isatty() on Windows
that had long made it into git.git's master branch.
Johannes Schindelin (1):
mingw: fix isatty() after dup2()
compat/mingw.h | 3 +++
From: Johannes Schindelin
Since a9b8a09c3c30 (mingw: replace isatty() hack, 2016-12-22), we handle
isatty() by special-casing the stdin/stdout/stderr file descriptors,
caching the return value. However, we missed the case where dup2()
overrides the respective file descriptor.
That poses a
From: Johannes Schindelin
Git for Windows ships with its own Perl interpreter, and insists on
using it, so it will most likely wreak havoc if PERL5LIB is set before
launching Git.
Let's just unset that environment variables when spawning processes.
To make this feature extensible (and
From: Johannes Schindelin
This is the convention elsewhere (and prepares for the case where we may
need to pass callback data).
Signed-off-by: Johannes Schindelin
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index
From: Johannes Schindelin
Signed-off-by: Johannes Schindelin
---
cache.h| 8
compat/mingw.c | 18 ++
config.c | 8
environment.c | 1 -
4 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/cache.h b/cache.h
index
In Git for Windows, we do not support running the Perl scripts with any
random Perl interpreter. Instead, we insist on using the shipped one (except
for MinGit, where we do not even ship the Perl scripts, to save on space).
However, if Git is called from, say, a Perl script running in a different
From: Johannes Schindelin
In the Git for Windows project, we have ample precendent for config
settings that apply to Windows, and to Windows only.
Let's formalize this concept by introducing a platform_core_config()
function that can be #define'd in a platform-specific manner.
This will allow
From: Johannes Schindelin
When passing a command-line to call an external diff command to the
difftool, we must be prepared for paths containing special characters,
e.g. backslashes in the temporary directory's path on Windows.
This patch is needed in preparation for the next commit, which will
From: Johannes Schindelin
On Windows, the authoritative environment is encoded in UTF-16. In Git
for Windows, we convert that to UTF-8 (because UTF-16 is *such* a
foreign idea to Git that its source code is unprepared for it).
Previously, out of performance concerns, we converted the entire
Once upon a time, the Git for Windows project had to decide what to do about
Unicode support, including how to deal with the environment. Karsten Blees
spent a ton of work on this, culminating in the final version
[https://groups.google.com/d/msg/msysgit/wNZAyScbJG4/viWz2KXU0VYJ] which
made it
From: Johannes Schindelin
As of cURL v7.60.0, the Secure Channel backend can use the certificate
bundle provided via `http.sslCAInfo`, but that would override the
Windows Certificate Store. Since this is not desirable by default, let's
tell Git to not ask cURL to use that bundle by default when
From: Johannes Schindelin
As of version 7.56.0, curl supports being compiled with multiple SSL
backends.
This patch adds the Git side of that feature: by setting http.sslBackend
to "openssl" or "schannel", Git for Windows can now choose the SSL
backend at runtime.
This comes in handy on
This topic branch brings support for choosing cURL's SSL backend (a feature
developed in Git for Windows' context) at runtime via http.sslBackend, and
two more patches that are related (and only of interest for Windows users).
Changes since v1:
* Reworded the commit message of v1's patch 2/3,
From: Johannes Schindelin
`git repack` can drop unreachable commits without further warning,
making the corresponding entries in `.git/shallow` invalid, which causes
serious problems when deepening the branches.
One scenario where unreachable commits are dropped by `git repack` is
when a `git
From: Johannes Schindelin
The `prune_shallow()` function wants a full reachability check to be
completed before it goes to work, to ensure that all unreachable entries
are removed from the shallow file.
However, in the upcoming patch we do not even want to go that far. We
really only need to
Under certain circumstances, commits that were reachable can be made
unreachable, e.g. via git fetch --prune. These commits might have been
packed already, in which case git repack -adlf will just drop them without
giving them the usual grace period before an eventual git prune (via git gc)
prunes
From: Johannes Schindelin
A `git fetch --prune` can turn previously-reachable objects unreachable,
even commits that are in the `shallow` list. A subsequent `git repack
-ad` will then unceremoniously drop those unreachable commits, and the
`shallow` list will become stale. This means that when
From: Johannes Schindelin
When switching the current working directory, say, in PowerShell, it is
quite possible to use a different capitalization than the one that is
recorded on disk. While doing the same in `cmd.exe` adjusts the
capitalization magically, that does not happen in PowerShell so
On Windows, file names are recorded case-sensitively, but looked up
case-insensitively. Therefore, it is possible to switch to a directory by
using incorrect case, e.g. cd documentation will still get you into the
Documentation subdirectory.
In Powershell, doing so will however report the
From: Johannes Schindelin
Since we cannot stash dirty submodules, there is no use in requiring
them to be clean (or stash them when they are not).
This brings the built-in rebase in line with the previous, scripted
version, which also did not care about dirty submodules (but it was
admittedly
This bug report came in via Git for Windows (already with version 2.19.0,
but I misread the reporter's enthusiasm to take matters into his own hands).
The culprit is, in a nutshell, that the built-in rebase tries to run git
stash only when the worktree is dirty, but it includes submodules in
From: Johannes Schindelin
It has been reported that dirty submodules cause problems with the
built-in rebase when it is asked to autostash. The symptom is:
fatal: Unexpected stash response: ''
This patch adds a regression test that demonstrates that bug.
Original report:
On Windows, file names are recorded case-sensitively, but looked up
case-insensitively. Therefore, it is possible to switch to a directory by
using incorrect case, e.g. cd documentation will still get you into the
Documentation subdirectory.
In Powershell, doing so will however report the
From: Johannes Schindelin
When switching the current working directory, say, in PowerShell, it is
quite possible to use a different capitalization than the one that is
recorded on disk. While doing the same in `cmd.exe` adjusts the
capitalization magically, that does not happen in PowerShell so
From: Johannes Schindelin
When we access IPv6-related functions, we load the corresponding system
library using the `LoadLibrary()` function, which is not the recommended
way to load system libraries.
In practice, it does not make a difference: the `ws2_32.dll` library
containing the IPv6
The search order for DLLs on Windows is a bit funny, and for system
libraries, it is recommended to use a strict search path.
In practice, this should not make a difference, as the library has been
loaded into memory already, and therefore the LoadLibrary() call would just
return the handle
From: Johannes Schindelin
In our fstat() emulation, we convert the file metadata from Win32 data
structures to an emulated POSIX structure.
To structure the code better, let's factor that part out into its own
function.
Note: it would be tempting to try to unify this code with the part of
This is yet another patch series in the slow wave of patches coming over
from Git for Windows.
With this change, we now use preciser timestamps to determine e.g. whether
the Git index is out of date. This change made it into Git for Windows
already in version 2.6.0, i.e. for a little over three
From: Johannes Schindelin
It was reported by Gábor Szeder and analyzed by Alban Gruin that the
built-in rebase stores only abbreviated stash hashes in the `autostash`
file.
This is problematic e.g. in t5520-pull.sh, where the abbreviated hash is
so short that it sometimes consists only of
1 - 100 of 323 matches
Mail list logo
