re: git installation - navigating fork(s) in the road on windows

[DerekNonGeneric]

the basic premise around this issue is that unix domain sockets were not designed for compat. w/ those found on windows

---

fork in the road on windows

---

for those on Windows 11 who have not yet installed Git while going thru and watching for suspicious software, we believe that the image below shows the correct answer one should choose:

we believe the correct answer above would alleviate so much pain

---

here is the last remaining doubt perhaps worth investigating as would be unique per user's machine:

using the native Windows ssh (an OpenSSH port)
—https://dev.gnupg.org/T3883#150265

Originally posted by @DerekNonGeneric in #1106 (comment)

[DerekNonGeneric]

sorry about this issue (was in a hurry to move all this content) — i am not sure if others feel the same way, but on macOS there was so little involved in git setup i can't remember being prompted for anything other than that friendly little reminder to set username/email config only once the install had finished (via the command line)

on windows, the whole wizard procedure is incredibly cringe experience causing me to sweat it out (literally);

incredibly cringe experience

pls, don't get me wrong about that statement — it looks beautiful! the being asked to answer questions that you may have no clue what they mean sux

[DerekNonGeneric]

now, this may be one of the most clear ways of visually understanding what in the world is going on BTS w/ Git client(s) on Windows and is probably the most popular installation method

even if only a handful of people read it, i think this wizard is fair game for a dedicated troubleshooting page where we break down what the ideal decisions are to be made in support of our highest goal of being able to perform cryptrographic signing of Git commits

if one knows beforehand that they would need to meet that goal of being 'bout that gpg-agent life,
the available choices one has left to make during the choose your own adventure game results in
a very narrow number of decision trees successfully arriving 'bout that life (afaict, curently)

[DerekNonGeneric]

very good — so now it's on!

i am going to start walking thru it now…

Step 2

Step 3

Step 4

Step 5

Alternatively, one may prefer VS Code, but let's not assume one even has that installed yet…

Step 6

Step 7

[DerekNonGeneric]

[…] we believe that the image below shows the correct answer one should choose:

we believe the correct answer above would alleviate so much pain

here is the last remaining doubt perhaps worth investigating as would be unique per user's machine:

using the native Windows ssh (an OpenSSH port)
—https://dev.gnupg.org/T3883#150265

Originally posted by @DerekNonGeneric in #1106 (comment)

hmmm, i am seeming to not have any more doubts:

@MathiasMagnus This change is to support Win32-OpenSSH by gpg-agent emulation of ssh-agent; You can use gpg-agent emulation of ssh-agent when you use Win32-OpenSSH. That is, you can use GPG auth subkey for Win32-OpenSSH.

Sorry, It's not related to gpg-agent's Unix domain socket emulation on Windows.

—https://dev.gnupg.org/T3883#167481

that issue was finally set to done earlier this month!

…

Step 8

Microsoft documentation focuses on how OpenSSH is used on Windows:

• Get started with OpenSSH for Windows

[DerekNonGeneric]

🟨 Ideally, the Languages & Tooling boxes would be outside the repository; Codespaces looks to be an interesting approach.

🔗 https://docs.github.com/en/codespaces/

---

if you are thinking that this method should be scrapped in favor of codespaces or the virtual machine… i couldn't agree more, much let's not derail this just yet since the codespaces-like solution is going to be our ultimate solution, which would not invalidate this procedure that we are documenting here

[DerekNonGeneric]

Step 9

Unless anyone has a good reason, otherwise:

Step 10

What ends up happening is that if you want to use Notepad for a quick edit, instead of a file with multiple lines visible on Unix-like machines, you end up seeing everything on the same line and can't do much about it, so this is preferred:

Step 11

I don't know whether our goal was to completely remove or stop usage of that Git Bash terminal emulator, but this information seem outdated now… (?)

[DerekNonGeneric]

i am going w/ MinTTY for now (not sure if we can update it later)

/cc @jorgebucaran as likely knows what should be selected here…

[DerekNonGeneric]

moving on since he is likely sleeping at this hour…

RE ⬇️:

openinf.github.io/.devcontainer/post-create.fish

Lines 10 to 11 in a69e0b8

	# To squelch yellow message re: specifying how divergent branches be reconciled.
	echo 'git config pull.rebase true' >> ~/.config/fish/config.fish # rebase

Step 12

after recently messing around w/ this setting…

… i believe the below setting is preferable since merge commits are kinda ugly and if we can avoid them, i think we should (i make efforts to do so¹)…

trying to think of situations where FF or merge would be necessary and basically if you need to create a merge commit, it seems like something got messed up along the way (?) — there is probably a good explanation, we will get back to this later as it seems like it has to do w/ culture…

Footnotes

1. https://gist.github.com/DerekNonGeneric/0a1d93edfc564bd86f313f96c159dde0 ↩

[DerekNonGeneric]

Step 13

Compare to Git's built-in credential helpers (Windows: wincred, macOS: osxkeychain, Linux: gnome-keyring/libsecret), which provide single-factor authentication support for username/password only.

GCM replaces both the .NET Framework-based Git Credential Manager for Windows and the Java-based Git Credential Manager for Mac and Linux.
—https://github.com/git-ecosystem/git-credential-manager

umm, trying to remember what it's like w/o this now…

🔗 https://www.gnupg.org/related_software/pinentry/index.html

[DerekNonGeneric]

Step 14 (extra options)

Short version: there is no exact equivalent for POSIX symlinks on Windows, and the closest thing is unavailable for non-admins by default unless Developer Mode is enabled and a relatively recent Windows 10 version is used. Therefore, symlink emulation support is only turned on by default when that scenario is detected. Support can be enabled by the user, via the core.symlinks=true config setting.
—https://github.com/git-for-windows/git/wiki/Symbolic-Links

no harm, no foul on the symlinks then since it's only enabled when necessary afaict

[DerekNonGeneric]

Step 15 (experimental options)

for this one:

• psuedo consoles: maybe not for my daily driver, but worth looking into soon (?)
• built-in system monitor: have heard good things about that already

[DerekNonGeneric]

Step 16 (done)

finally!

i am going to reboot now since plenty of consoles/terminals open