Skip to content

Releases: git-for-windows/git-snapshots

Mon, 29 Jul 2024 10:56:11 -0700

25 Jan 10:24
Compare
Choose a tag to compare
Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Wed, 24 Jul 2024 12:48:11 -0700

25 Jan 10:24
Compare
Choose a tag to compare
Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Thu, 18 Jul 2024 13:49:28 -0700

25 Jan 10:24
Compare
Choose a tag to compare
Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Thu, 18 Jul 2024 14:00:16 +0200

25 Jan 10:23
8c57d22
Compare
Choose a tag to compare
asciidoctor: fix `synopsis` rendering (#5064)

Since 76880f0510c (doc: git-clone: apply new documentation formatting
guidelines, 2024-03-29), the synopsis of `git clone`'s manual page is
rendered differently than before; Its parent commit did the same for
`git init`.

The result looks quite nice. When rendered with AsciiDoc, that is. When
rendered using AsciiDoctor, the result is quite unpleasant to my eye,
reading something like this:

	SYNOPSIS

	 git clone
	  [
	 --template=
	 <template-directory>]
		  [
	 -l
	 ] [
	 -s
	 ] [
	 --no-hardlinks
	 ] [
	 -q
	 ] [
	[... continuing like this ...]

Even on the Git home page, where AsciiDoctor's default stylesheet is not
used, this change results in some unpleasant rendering where not only
the font is changed for the `<code>` sections of the synopsis, but
padding and a different background color make the visual impression
quite uneven: compare https://git-scm.com/docs/git-clone/2.45.0 to
https://git-scm.com/docs/git-clone/2.44.0.

To fix this, let's apply the method recommended by AsciiDoctor in
https://docs.asciidoctor.org/asciidoctor/latest/html-backend/default-stylesheet/#customize-docinfo
to partially override AsciiDoctor's default style sheet so that the
`<code>` sections of the synopsis are no longer each rendered on their
own, individual lines.

This fixes https://github.com/git-for-windows/git/issues/5063.

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
documentation 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.

For a single-commit pull request, please *leave the pull request
description
empty*: your commit message itself should describe your changes.

Please read the "guidelines for contributing" linked above!

Mon, 15 Jul 2024 13:34:00 +0200

25 Jan 10:23
f46b4dc
Compare
Choose a tag to compare
run-command: refine Git LFS check on Windows 7 (#5059)

In commit git-for-windows/git@46d14a6f7189a604a0812b143dc5c51488a01895
of PR git-for-windows/git#5042 the `wait_or_whine()` function in
`run-command.c` was revised to
[call](https://github.com/git-for-windows/git/blob/b105301ef9107c8c2980a24eca89a2992a1c074b/run-command.c#L571)
a new function in the case where an executable fails to run, to check
whether this was caused by a Git LFS binary compiled with a version of
the Go language that no longer supports Windows 7. This change was made
to address the issue reported in git-for-windows/git#4996.

The new function, `win32_warn_about_git_lfs_on_windows7()`,
[performs](https://github.com/git-for-windows/git/blob/b105301ef9107c8c2980a24eca89a2992a1c074b/compat/win32/path-utils.c#L226-L232)
several initial checks to test whether the failed executable returned
the exit code `0x0b00` and is named `git-lfs`, and whether we are
running Windows 7 or not. Only if all these conditions are met does it
then proceed to try to extract the Go language version from the binary
file and check whether it is 1.21.0 or higher.

However, these initial checks may not cover all possible use and failure
cases.

First, when running in Git Bash (in a Windows 7 SP1 virtual machine),
the exit code seen from a recent Git LFS executable was `0x02`, so we
also want to check for that value as well as `0x0b00`.

Second, the name of the executable may not always be entirely lowercase,
since it is possible to invoke Git LFS through Git by running, for
example, `git LFS ls-files` (at least, on Windows, and with a
case-insensitive filesystem). We therefore need to ignore case when
checking the executable's name.

And third, the name of the executable may not have a trailing space
character, so we also need to check for the case where the name in
`argv0` is simply `git-lfs`.

With these changes, we can more reliably detect a failure of the Git LFS
executable in a wider range of circumstances.

Fri, 12 Jul 2024 22:27:56 +0200

25 Jan 10:23
Compare
Choose a tag to compare
Merge 'readme' into HEAD

Add a README.md for GitHub goodness.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Wed, 10 Jul 2024 11:49:26 +0200

25 Jan 10:23
dbc64e8
Compare
Choose a tag to compare
run-command: be helpful when Git LFS fails on Windows 7 (#5042)

Git LFS is now built with Go 1.21 which no longer supports Windows 7.
However, Git for Windows still wants to support Windows 7.

Ideally, Git LFS would re-introduce Windows 7 support until Git for
Windows drops support for Windows 7, but that's [not going to
happen](https://github.com/git-for-windows/git/issues/4996#issuecomment-2176152565).

The next best thing we can do is to let the users know what is
happening, and how to get out of their fix, at least.

This is not quite as easy as it would first seem because programs
compiled with Go 1.21 or newer will simply throw an exception and fail
with an Access Violation on Windows 7.

The only way I found to address this is to replicate the logic from Go's
very own `version` command (which can determine the Go version with
which a given executable was built) to detect the situation, and in that
case offer a helpful error message.

This addresses https://github.com/git-for-windows/git/issues/4996.

/cc @chrisd8088

Thu, 4 Jul 2024 20:01:50 +0200

25 Jan 10:23
15e18f2
Compare
Choose a tag to compare
Fallback to AppData if XDG_CONFIG_HOME is unset (#5030)

#316

Tue, 2 Jul 2024 09:11:39 +0200

25 Jan 10:22
02e091b
Compare
Choose a tag to compare
monitor-components: add InnoSetup (#5032)

Let's also keep an eye out for new InnoSetup versions, as we rely on
using reasonable secure versions of it.

Fri, 21 Jun 2024 13:11:54 +0200

25 Jan 10:22
80ed467
Compare
Choose a tag to compare
mingw: drop bogus (and unneeded) declaration of `_pgmptr` (#5017)

Companion to https://github.com/gitgitgadget/git/pull/1752.

This (hopefully) addresses
https://github.com/git-for-windows/git/issues/5016.