SDK discussion location?

[PhilipOakley]

Is this the best location for discussions about the Git-for-Windows SDK (software development kit) and how it is boot-strapped?

The Build-Extra repo looks to have its Issues section disabled, which is where I expected to clarify a few points, hence this question.

My back-story problem (XY style) was, historically, that my SDK had become out of date and wouldn't update properly (99% resolved via the newly-introduced update-via-pacman.ps1). This allowed me to recompile Git in the SDK, but it still won't fetch from remotes, but otherwise feels functional (no, I didn't run the tests, which take far too long ;-).

Looking at the SDK / Build-Extra, the README.md gives the 'what & where' of the general Git for Windows contents, and that it will 'perform an initial build', but didn't cover the 'how & why' (of the SDK install process) to help debug my 'lack of fetch' situation. I was looking to avoid the 'dump the SDK and start again' option..

Cross checking my config values with the regular GfW install, I see that the sslbackend's are different for my SDK and GfW, using schannel and openssl respectively. The GfW also has the system config sslcainfo set, along with core.fscache and core.symlinks. I'm not sure if the change of sslbackend config value is significant for the SDK update problem that shows as fetch not working.

The newish sdk command methods post dates my earlier understanding of the SDK install [1], so there are a few 'gotcha' steps I (and possibly others) don't immediately see.

My desired outcome would be to:

1. provide a PR updating the README.md with details of where to discuss the (perceived) Build-Extra issues,
2. provide a PR updating the README.md with details of how the SDK has its triple level (or more?) of bootstrapping to create the 7-zip installer, download the SDK repo via the batch file, .. etc. (first time bash commands, clones, pacman, ) .., and compile the code, along with the background requirement to keep the SDK repos up to date,
3. update the FAQs to provide details of the .ps1 method and, hopefully, also a 'reinstall-sdk' method that avoids the perception of 'dump and start again'

Is this the right place to discuss the SDK?

[dscho]

it still won't fetch from remotes

You probably inadvertently ended up with mismatched mingw-w64-curl/mingw-w64-openssl versions.

Is this the right place to discuss the SDK?

Yes. What are your questions, concretely?

[PhilipOakley]

it still won't fetch from remotes

You probably inadvertently ended up with mismatched mingw-w64-curl/mingw-w64-openssl versions.

Is there a particular way of determining the 'correct' versions for curl/openssl.

The errors I see are:

$ git fetch --all
Fetching my
error: could not fetch my
Fetching origin
error: could not fetch origin
Fetching git
error: could not fetch git
Fetching junio
error: could not fetch junio

My attempts at using the update-via-pacman.bat (in cmd, log Attempted update 21March23.txt), or update-via-pacman.ps1 (in powershell

) and the direct pacman -Syu (

) haven't made any real progress other than highlight other problems.

I'll at least do a PR covering (1.) that here is the place to discuss the build-extra issues.

I've made some progress on understanding the overall modern SDK organisation with respect to how/when pacman is utilised, though there are still a few grey areas to allow a PR against point 2, especially to help others without the breadth of knowledge needed for some issues.

[dscho]

Looks like you're running into the issues described at git-for-windows/git-sdk-64@5c846f3.

The best way to get out of the fix is to re-clone the SDK, I am afraid. That will come with the pacman.conf that prevents your updates from hosing the system.

[PhilipOakley]

For the failure to re-install asciidoctor, one possible reason is that the directory names I have, e.g. mingw-w64-i686-asciidoctor-extensions-150.9846486-1, don't appear to match the [0-9]* pattern portion given in update-via-pacman.ps1 #3594

if (Test-Path var/lib/pacman/local/mingw-w64-*-asciidoctor-extensions-[0-9]* -PathType Container) {

Or am I misunderstanding something about the pattern match?

[PhilipOakley]

Or am I misunderstanding something about the pattern match?

Looks like I was confusing RegEx style with WildCards (So it does match)

The follow-up bash scriptlet then doesn't find asciidoctor because gem doesn't list it.

Running the

$ gem install asciidoctor
ERROR:  While executing gem ... (Gem::Exception)
    OpenSSL is not available. Install OpenSSL and rebuild Ruby (preferred) or use non-HTTPS sources
        C:/git-sdk-64/mingw64/lib/ruby/3.1.0/rubygems/request.rb:47:in `configure_connection_for_https'

then bombs out as it doesn't discover OpenSSL.
The journey down the rabbit hole continues 😃 .

[dscho]

This is precisely the problem described in git-for-windows/git-sdk-64@5c846f3, and #4350 is tracking the effort to mitigate those issues more robustly.

[PhilipOakley]

Thanks for clarifying. I'd seen the #4350 but had it in my mind that it would be a future (soon) problem, rather than effectively 'pre-existing'. I'd missed 5c846f3 's relevance.

I may try replicating the steps of the install, without the init, (i.e. the fetch depth=1) and see how that goes, rather than the 're-clone SDK' (which feels too much like https://xkcd.com/1597/ 😉).

My remaining query is to try to understand how the pacman error message was created to better understand that part, but that's incidental. e.g. the:

(32/41) upgrading mingw-w64-x86_64-git                                                                   [#############################################################] 100%
/tmp/alpm_4qFbTz/.INSTALL: line 2: die: command not found
mkdir: cannot create directory '': No such file or directory
error: command (/usr/bin/bash /usr/bin/bash -c . /tmp/alpm_4qFbTz/.INSTALL; post_upgrade 2.40.0.1.1d90ca2906-1 2.40.0.rc0.windows.1-1 ) failed to execute correctly

Still to do the PR for the point 1 (build-extra / SDK questions: use the GfW Issues/Discussion pages).

[dscho]

/tmp/alpm_4qFbTz/.INSTALL: line 2: die: command not found

That's simply a bug in https://github.com/git-for-windows/MINGW-packages/blob/2a1de13472e0894437a572c5c1e34d3f42e67612/mingw-w64-git/git.install#L2 where it assumes that the die function exists, but it does not.

The underlying bug that this buggy call wants to report is that MINGW_PREFIX unexpectedly has not been set. I'm not quite sure what is happening there, as it should be set here, here, here, here, here, here, unless we're not even running in MINGW mode.