Support cygwin git #7998

rcarmo · 2016-06-22T11:56:04Z

VSCode Version: 1.2.1
OS Version: Windows 10 Build 14367

Steps to Reproduce:

Install Cygwin
Edit .vscode/settings.json to set git.path to point to "\\cygwin64\\bin\\git.exe
VS Code throws up an error message of ENOENT: no such file or directory, lstat 'C:\cygdrive', as described here

This is, of course, because Cygwin namespaces the filesystem differently. However, doing this (which usually fixes things in other tools):

        "git.path": "\\cygwin64\\bin\\bash.exe git",

...then results in further confusion as Code apparently does not have a way to correctly set the environment for the git process, which then defaults to the wrong PATH:

git fetch
git show HEAD:.vscode/settings.json
git show HEAD:.vscode/settings.json
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
git fetch
Could not create directory '/c/cygwin64/home/USERNAME/.ssh'.
ssh_askpass: exec(/usr/local/bin/win-ssh-askpass.exe): No such file or directory
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Trying to set PATH, HOME, etc. inline in the bash command line above fails for some reason I cannot yet fathom, but I would suggest a configuration setting git.env be created so that the environment external Git tools can be pre-configured (this would also benefit the Linux and OSX ports).

As to why this is necessary and why I can't use other Git binaries on Windows, the reason is simple:

Cygwin does Git over SSH "right", with completely identical setup in terms of SSH keys, options, CR/LF encoding, etc. Current Git for Windows simply does not work for my use case (I've tried), and, obviously, the Linux Subsystem doesn't help with this either.

The text was updated successfully, but these errors were encountered:

joaomoreno · 2016-06-22T20:32:58Z

Duplicate of #7361. We don't support cygwin git, sorry.

We've been using Git for Windows successfully in the team, complete with SSH keys, options, line ending encodings et al. What is the actual issue you get with it?

rcarmo · 2016-06-22T20:34:59Z

Hmmm. So this is a dupe of a ticket that's closed because we've "just never really looked into it"?

My issue is that I can use exactly the same setup with Cygwin than on Linux without having to sort out the (rather clunky) Git for Windows options and separate management of SSH keys. It's just less friction for someone who has to work routinely on both environments. Personally, I would very much like not to have to use Git for Windows at all and just rely on the Cygwin binaries.

Also, you missed my suggestion of adding a git.env setting to set the environment for Git binaries, which is also useful on other platforms. Should I file an issue for that separately?

joaomoreno · 2016-06-22T20:45:11Z

If #7361 were open we would close this one the same way. It is a duplicate, in any case.

Apologies for coming out harsh.

Let me expand a bit on just never really looked into it. Code already needs to support whichever version of git you have installed in whichever platform you are using it. It is a non-trivial task that gets another complexity fold as soon as we add git flavours. We've found that Git for Windows handles the great majority of the tasks users need and I've personally have yet to find a reason that would make me use cygwin instead.

Of course, I can be wrong and I'm definitely interested in someone proving me wrong. That's why I asked about the actual issue you face. If it is really something Git for Windows does not support, of course we'll reconsider our position towards cygwin, and we'll work towards that.

rcarmo · 2016-06-22T20:53:57Z

It's all about integration. When you use Cygwin and its userland (bash, CLI tools, SSH, etc.), you don't need an extra terminal emulator like PuTTY, you can use standard Git plugins that rely on Perl/Python etc. seamlessly, and you don't need to set up a copy of your SSH keys anyplace else.

Right now, the current (stunted and incomplete) UNIX userland clone that ships with Git for Windows doesn't provide me those affordances. Also, I can't set GIT_AUTHOR_* and GIT_COMMITTER_* on a per-repo basis using Git for Windows - it's just a surreal amount of pain to deal with that kind of thing inside it, when it all works perfectly in Cygwin.

With an environment setting I might not only actually get Cygwin Git to work (I suspect it's just a matter of setting the right HOME and a few more variables) but also have GIT_* settings set on a per-project basis for me inside VS Code. And this last bit will benefit every other platform, too.

joaomoreno · 2016-06-22T21:02:54Z

Alright, let's keep this open for tracking the support. A PR would be much appreciated as we'll likely not have cycles to look into it any time soon.

Maybe next time I'm in the Lisbon office, I'll ping you and we'll get it working in an afternoon. 😉

samiworks · 2016-06-24T16:38:39Z

I created a symlink and it worked for me:
http://stackoverflow.com/questions/36508177/visual-studio-code-cannot-detect-cygwin-git-exe-path/37980938#37980938

joaomoreno · 2016-07-04T13:44:33Z

@rcarmo Did you try this?

rcarmo · 2016-07-04T17:58:17Z

Not yet, kind of tied up with FY16 still. Will give it a go next weekend and see if it works on my box and a fresh install (never underestimate the power of upgrades where it regards breaking things).

On 04 Jul 2016, at 14:45 , João Moreno [email protected] wrote:

@rcarmo https://github.com/rcarmo Did you try this?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #7998 (comment), or mute the thread https://github.com/notifications/unsubscribe/AAX96yMsQpPeoo5orUAdryk1tJMc5ipXks5qSQ5ggaJpZM4I7sqV.

samiworks · 2016-07-08T18:32:23Z

someone had a similar issue here too and it worked: #1982

rcarmo · 2016-07-08T18:35:43Z

I'm going to have a go at this (both reproducing and understanding exactly why the symlink works, and if it works with my git plugins) within the next few days and will report back.

On 08 Jul 2016, at 19:32, Bastien Calestroupat [email protected] wrote:

someone had a similar issue here too and it worked: #1982

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

rcarmo · 2016-07-15T10:29:22Z

Brief status update: I'm still having trouble with SSH/askpass at this point. Trying to debug.

rcarmo · 2016-07-30T08:47:21Z

I've been using it alongside Cygwin, and the answer is no. Unless I go full X-Windows and run VS Code inside LXSS, I can't get the degree of integration I need (plus the LXSS console is still not as nice as mintty, but that's beside the point here)

I made some headway recently using a little executable shim to wrap Cygwin's git, but I'm still missing something regarding PATH and environment variables. I still think being able to set environment variables prior to Git execution is the way around this, but time hasn't been on my side recently.

jastorgalj · 2016-09-07T17:30:50Z

Solution for me (Windows 10 - git from cygwin)
create dir - mkdir c:\cygdrive
open a cmd and goto - cd c:\cygdrive
créate link to c:\ - mklink /j "c" c:\
and ready..

rcarmo · 2016-09-22T10:53:02Z

That doesn't work for me for some reason - I get errors trying to find my home directory for SSH keys (Cygwin apparently gets confused and does stuff like /c/cygwin64/home/username/.ssh

rcarmo · 2016-09-23T08:36:02Z

I had partial success today by setting a couple of links and tweaking environment variables and managed to have Cygwin git do local commits, but there were two issues:

the sync icon turned into a cloud+arrow icon (which means VSCode wasn't able to completely figure out the output from the Cygwin git binary). Pushing to the remote repo worked, but...
ssh-ask-pass did not work correctly, and did not respect the environment variables set by ssh-agent (so I got an SSH password prompt on every git operation)

The second point essentially circles back to one of my earlier points - without being able to set environment variables for git within VS Code, this will likely always be broken in some way -- some people might get it to work with passwordless keys, but it's not a definitive solution.

Also (and this is just an aside), getting this to partially work completely broke "regular" Windows Git (which uses a variant of Cygwin):

git pull
      0 [main] ssh 9472 C:\Program Files\Git\usr\bin\ssh.exe: *** fatal error - add_item ("\??\C:\Program Files\Git", "/", ...) failed, errno 1
Stack trace:
Frame        Function    Args
000FFFF9BB0  0018007164E (00180273652, 00180224DD9, 000FFFF9BB0, 000FFFF8B30)
000FFFF9BB0  00180046669 (000FFFFABE0, 000FFFF9BB0, 1D21574853C4D14, 00000000000)
000FFFF9BB0  001800466A2 (000FFFF9BB0, 00000000001, 000FFFF9BB0, 505C3A435C3F3F5C)
000FFFF9BB0  001800DF22B (00000000000, 000FFFFCE00, 001800CEE68, 1D215748E2D2E24)

joaomoreno · 2016-09-23T08:40:51Z

The cloud+arrow icon simply means the current branch you have checked out doesn't have an upstream branch configured. Once it does, it should show the sync icon. This must've been a coincidence that you checked out such a branch.

So... would it work if you set a few env variables for when Code calls git?

rcarmo · 2016-09-23T08:44:41Z

@joaomoreno: I believe so, yes. The experiment I did with an executable wrapper a while back was partially successful.

Maybe something like this would be feasible:

{
    "git.path": "..."
    "git.env": {
        "foo": "bar"
        ...
    }
}

joaomoreno · 2016-09-23T08:46:43Z

And are the variables predictable for each system? Meaning, could it simply be a git.cygwin: true setting and we just build it in?

rcarmo · 2016-09-23T08:56:18Z

Nope, I have to set at least these for the SSH agent:

SSH_ASKPASS='C:\cygwin64\usr\local\bin\win-ssh-askpass.exe'
SSH_AUTH_SOCK=/tmp/ssh-59iOCz4fyxRZ/agent.12660

I can pin down SSH_AUTH_SOCK, but that's usually random, and I will need extra variables for some Git plugins and environments. Also, might be helpful to avoid future issues like #6202

rcarmo · 2016-09-23T08:57:51Z

Also, regarding the cloud+arrow bit, there's definitely something amiss here. I've tried Windows Git and Cygwin git on the same repo, same branch, no changes, and gotten:

cloud+arrow for Cygwin git (and am unable to do git push)
sync wheel for Windows git (and can do git push)

Might be a version issue (Cygwin git is 2.8.3), but you're right, VSCode can't figure out the remote for some reason.

$ git remote -v
origin  [email protected]:rcarmo/azure-REDACTED.git (fetch)
origin  [email protected]:rcarmo/azure-REDACTED.git (push)

AnrDaemon · 2019-09-09T18:59:45Z

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

neontorrent · 2019-09-09T19:21:43Z

This is an issue between VS Code (which relies on git itself too much) and Cygwin git (which uses Cygwin directory layout, which follows POSIX FHS).
To make VS Code understand Cygwin paths, it should either be told to expect them, or use cygpath to convert them to native form.

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path, and VSCode does not have to understand cygwin path, but it still does not work perfectly. The initial Git init works, but the file listing and diff do not work.

I briefly checked the VSCode before. When calling Git, it does not always use absolute path returned from Git command. It parses URI with a root path returned from other function, which does not seem to work properly with non official git binary. You can check that if you like.

AnrDaemon · 2019-09-09T19:33:44Z

Unfortunately, VS Code tries hard to find specifically "git.EXE", even if told to use "git.sh" wrapper (which has appropriate shell association defined).
I've had a small success with "git.cmd" wrapped around "git.sh", trying that route now.

AnrDaemon · 2019-09-09T19:35:57Z

However, a more native approach would be preferred.
Cygwin, despite its interoperability issues on filesystem level, has way better integration with Windows itself. In fact, better to the level that WSL could never achieve. Ever. Due to its nature.

AnrDaemon · 2019-09-10T08:00:49Z

You can create a wrapper for that in Windows batch file, which calls cygpath to output windows path

Now, I recalled why did I switch from CMD to TakeCommand/Console.
Insane, unusable quoting rules of CMD, compounded by inability to control arbitrary number of batch file parameters in an efficient way, are basically a showstopper to any effective scripting.

igordcard · 2019-09-17T23:20:39Z

Just adding myself here as another person who would really like to continue to use cygwin... + vscode.

lalawue · 2020-01-25T13:03:53Z

I think cyg-git might be able to solve the problem. It provides a "Git for Windows" virtually. You only need Cygwin and its packages.

https://github.com/nukata/cyg-git

it works for me under Win 7

dmak · 2021-01-07T15:11:01Z

Just tried the script from Cygwin Git + VS Code compatibility and it didn't work with the following error message in Git output:

> git ls-files --stage -- D:\Workspace\test\platformio.ini
fatal: D:\Workspace\test\platformio.ini: 'D:\Workspace\test\platformio.ini' is outside repository at '/cygdrive/d/Workspace/test'

@nukata
Many thanks for your contribution, it works. Just one minor remark: what about re-writing the script on bash? bash is for sure present on all installations and most are familiar with it. I am not sure if I did this rewriting correctly as I couldn't test the script thoroughly for the case when wrap_output=yes, but here it goes:

#!/bin/bash

wrap_output=""
argv=("$@")

for ((i = 0; i < $#; i++))
do
	arg="${argv[$i]}"
	if [ $i = 0 -a "$arg" = 'rev-parse' ]
	then
		wrap_output=yes
	elif [[ -n "$arg" && "$arg" != -* ]]
	then
		argv[i]=`cygpath -u "$arg"`
	fi
done

if [ $wrap_output ]
then
	if out=`git "${argv[@]}"`
	then
		if [ -n "$out" ]
		then
			if [[ $out = -* ]]
			then
				echo "$out"
			else
				cygpath -w "$out"
			fi
		fi
	else
		x=$?
		echo "$out"
		exit $x
	fi
else
	exec /usr/bin/git "${argv[@]}"
fi

ViPod5 · 2021-03-09T13:54:12Z

@dmak Thank you! Great work, just one tiny adjustment. Either initially prefix the PATH with /usr/bin or change the git execs to /usr/bin/git or you'll end up with an infinite loop within the script.

DanKaplanSES · 2021-09-27T00:32:37Z

@joaomoreno Clarification: if someone were to submit a PR to fix this, would it be ~~rejected~~ considered?

I'm asking because if you would conditionally accept a PR, technically, shouldn't this issue remain open?

danfly09 · 2022-04-14T17:17:13Z

But why is it complicated to have git integration with VSCode?
In my particular case, I don't think I have a problem with the path. It seems that VSCode can detect that I have an installation of git and that's because I added to PATH my cygwin bin folder, and then I can execute git commands from CMD and PowerShell without issues.

However, the editor fails to track the repositories completely.

AnrDaemon · 2022-04-15T07:25:44Z

This is because git reporting paths unexpected to VS Code.
Plus it is reporting them inconsistently. Sometimes relative, sometimes absolute, from the same command.
This is not a simple issue, unfortunately.

danfly09 · 2022-04-15T17:30:27Z

src/base/common/process.ts

// Native sandbox environment
if (typeof globals.vscode !== 'undefined' && typeof globals.vscode.process !== 'undefined') {
	const sandboxProcess: INodeProcess = globals.vscode.process;
	safeProcess = {
		get platform() { return sandboxProcess.platform; },
		get arch() { return sandboxProcess.arch; },
		get env() { return sandboxProcess.env; },
		cwd() { return sandboxProcess.cwd(); }
	};
}

I was wondering if an additional check can be made here so if sandboxProcess.platform is win32, then check for a Cygwin installation, this can be checked by executing the command,
cygcheck --version
Cygwin bin folder needs to be added to the Path variable. A user configuration variable can also do the work of checking whether VSCode should run natively or under a Cygwin session.

In that scenario
get platform() { return linux } instead of win32
I believe the compatibility for a real linux OS should then work.

Another option might be a container, but I have no experiencie with VScode containers or extensions, but the idea is there, to be implemented.

AnrDaemon · 2022-04-16T12:41:17Z

You can have multiple Cygwin environments installed on the same PC. And none of them in the $PATH.
I've long since abandoned the hope and installed Git-for-Windows (and told VS Code to use specifically that one).

ViPod5 · 2022-04-16T16:51:20Z

I've been using this https://github.com/nukata/cyg-git with success.

…

On Sat, Apr 16, 2022 at 2:41 PM AnrDaemon ***@***.***> wrote: You can have multiple Cygwin environments installed on the same PC. And none of them in the $PATH. I've long since abandoned the hope and installed Git-for-Windows (and told VS Code to use specifically that one). — Reply to this email directly, view it on GitHub <#7998 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADM6ZK73Q6EIR2CQEYNIWVLVFKYPZANCNFSM4CHOZKKQ> . You are receiving this because you commented.Message ID: ***@***.***>

maksim-pinguin · 2022-05-04T17:28:38Z

as noted in #148720 i believe supporting the configured integrated terminal is the way to go. extensions like gitlense do this e.g.

AnrDaemon · 2022-05-05T15:15:07Z

This is not enough.
Cygwin paths are inherently different from Windows paths, and VS Code do not understand that distinction.

ohhmm · 2024-01-13T21:55:09Z

Vscode could have Git auto-detection for Windows from different sources:

Program Files\Git
Visual Studio Git
Cygwin git could be auto-detected by its exe file location

It may be hardcoded preference or highest version preferred.

AnrDaemon · 2024-01-14T17:52:13Z

Vscode could have Git auto-detection for Windows from different sources:

Program Files\Git

Visual Studio Git

Cygwin git could be auto-detected by its exe file location

It may be hardcoded preference or highest version preferred.

Yet again - this is not about git.exe location, it is about Cygwin paths support.

ohhmm · 2024-01-15T07:54:42Z

Yes, I got it @AnrDaemon
Could you try to run Cygwin's git from cmd by its Windows path, please?

AnrDaemon · 2024-01-16T12:52:27Z

Yes, you could. That's not the problem.
The problem starts when Cygwin Git return Cygwin paths which VS Code don't know how to interpret.
Or when VS Code provide Windows paths that means nothing to Cygwin Git.

It requires some extra care inside VS Code itself, and even then not fully fool proof, as other extensions may run Git directly by themselves.

DanKaplanSES · 2024-01-16T20:08:20Z

@AnrDaemon Yep. it's not just the difference in slashes, absolute paths and cygwin start with /cygdrive/<drive letter> and in Windows, start with <drive letter>:\\. The last paragraph in your comment is especially tricky.

Here's my workaround, and I didn't come up with it on my own. In fact, I may be summarizing something already in this thread.

I added this line to settings.json: "git.path": "C:\\cygwin64\\home\\<user>\\vscode_git_compatibility\\cygpath-git-vscode.bat",.

$ cat cygpath-git-vscode.bat:

@echo off

REM wrapper to convert linux paths to windows
REM so vscode git integration will work with cygwin
REM "git.path"="C:\\this\\file.bat" in settings.json

setlocal
set PATH=C:\cygwin64\bin;%PATH%

if "%1" equ "rev-parse" goto rev_parse
git %*
goto :eof
:rev_parse
for /f %%1 in ('git %*') do cygpath -w %%1

I don't know why, and I don't know if it's actually used (running ag -l 'cygpath-git-editor.sh' in my home directory finds nothing), but I have another file in C:\\cygwin64\\home\\<user>\\vscode_git_compatibility\\ named cygpath-git-editor.sh. $ cat cygpath-git-editor.sh:

#!/bin/bash

# wrapper to convert linux paths to windows
# so vscode will work as a git editor with cygwin
# editor="/home/this/file.sh" in .gitconfig

# extract last argument (the file path)
for last; do true; done

# get all the initial command arguments
all="${@:1:$(($#-1))}"

# launch editor with windows path
code $all $(cygpath -w $last)

I'm kind of in a rush so I don't have the time to verify if these are the only steps, but it is what I currently use. I hope this can be of help to someone. I want to reiterate that @AnrDaemon 's last paragraph still applies.

AnrDaemon · 2024-01-17T23:31:07Z

The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.

DanKaplanSES · 2024-01-17T23:50:18Z

The workaround is to install Git-For-Windows in a separate directory and point VS Code to it.

Are providing an alternative workaround or explaining mine?

AnrDaemon · 2024-01-17T23:56:29Z

Restating the obvious.

DanKaplanSES · 2024-01-18T00:20:13Z

Restating the obvious.

Not obvious enough, it seems. It looks like you said this back in 2022, but I hadn't noticed until now. The next reply provides a different workaround that may have buried yours.

If you use the git-for-windows work around, can you still use cygwin's git in the same project, or do they step on each other's toes? I use the git command line 95% of the time; I only need VS Code to understand enough to mark my files as modified.

AnrDaemon · 2024-01-18T12:20:01Z

I do.

Cygwin is my go-to *NIX tools, I only install native ports/equivalent tools when one of the following statements is true:

The application provides exclusively network functionality or otherwise not restricted by path mangling (webservers, tools that talk to STDIO exclusively). Native tools usually more performant because they are not using POSIX API conversion layer.
An external native application wants to pass paths to the tool, and I can not control what exactly is passed. (VS Code talking to Git, Subversion, Meld etc.)

dbaeumer added the git GIT issues label Jun 22, 2016

dbaeumer assigned joaomoreno Jun 22, 2016

joaomoreno closed this as completed Jun 22, 2016

joaomoreno reopened this Jun 22, 2016

joaomoreno changed the title ~~Cannot use Cygwin git binary~~ Support cygwin git Jun 22, 2016

joaomoreno added feature-request Request for new features or functionality help wanted Issues identified as good community contribution opportunities labels Jun 22, 2016

joaomoreno modified the milestones: July 2016, Backlog Jun 22, 2016

gjsjohnmurray mentioned this issue Mar 25, 2021

The Source control extension shows every file as "modified" because it uses wrong git executable #119845

Closed

This was referenced May 4, 2022

Some git commands use the terminal and require git to be in the windows PATH variable gitkraken/vscode-gitlens#1767

Open

integrated terminal profile is not respected by git build in #148720

Closed

Support cygwin git #7998

Support cygwin git #7998

Comments

rcarmo commented Jun 22, 2016

joaomoreno commented Jun 22, 2016

rcarmo commented Jun 22, 2016 • edited Loading

joaomoreno commented Jun 22, 2016

rcarmo commented Jun 22, 2016

joaomoreno commented Jun 22, 2016

samiworks commented Jun 24, 2016

joaomoreno commented Jul 4, 2016

rcarmo commented Jul 4, 2016

samiworks commented Jul 8, 2016

rcarmo commented Jul 8, 2016

rcarmo commented Jul 15, 2016

rcarmo commented Jul 30, 2016

jastorgalj commented Sep 7, 2016

rcarmo commented Sep 22, 2016

rcarmo commented Sep 23, 2016

joaomoreno commented Sep 23, 2016

rcarmo commented Sep 23, 2016

joaomoreno commented Sep 23, 2016 • edited Loading

rcarmo commented Sep 23, 2016 • edited Loading

rcarmo commented Sep 23, 2016 • edited Loading

AnrDaemon commented Sep 9, 2019

neontorrent commented Sep 9, 2019

AnrDaemon commented Sep 9, 2019

AnrDaemon commented Sep 9, 2019

AnrDaemon commented Sep 10, 2019

igordcard commented Sep 17, 2019

lalawue commented Jan 25, 2020

dmak commented Jan 7, 2021 • edited Loading

ViPod5 commented Mar 9, 2021

DanKaplanSES commented Sep 27, 2021 • edited Loading

danfly09 commented Apr 14, 2022 • edited Loading

AnrDaemon commented Apr 15, 2022

danfly09 commented Apr 15, 2022 • edited Loading

AnrDaemon commented Apr 16, 2022

ViPod5 commented Apr 16, 2022 via email

maksim-pinguin commented May 4, 2022

AnrDaemon commented May 5, 2022

ohhmm commented Jan 13, 2024

AnrDaemon commented Jan 14, 2024

ohhmm commented Jan 15, 2024

AnrDaemon commented Jan 16, 2024

DanKaplanSES commented Jan 16, 2024 • edited Loading

AnrDaemon commented Jan 17, 2024

DanKaplanSES commented Jan 17, 2024

AnrDaemon commented Jan 17, 2024

DanKaplanSES commented Jan 18, 2024 • edited Loading

AnrDaemon commented Jan 18, 2024

rcarmo commented Jun 22, 2016 •

edited

Loading

joaomoreno commented Sep 23, 2016 •

edited

Loading

rcarmo commented Sep 23, 2016 •

edited

Loading

rcarmo commented Sep 23, 2016 •

edited

Loading

dmak commented Jan 7, 2021 •

edited

Loading

DanKaplanSES commented Sep 27, 2021 •

edited

Loading

danfly09 commented Apr 14, 2022 •

edited

Loading

danfly09 commented Apr 15, 2022 •

edited

Loading

DanKaplanSES commented Jan 16, 2024 •

edited

Loading

DanKaplanSES commented Jan 18, 2024 •

edited

Loading