Add .gitattributes file by YutongZhuu · Pull Request #1396 · eisop/checker-framework

YutongZhuu · 2025-09-14T01:22:43Z

I believe this command: git config --global core.autocrlf true should only be used on Windows. I got confused by this so I thought it would be a good idea to be more explicit.

Thanks for reviewing.

thisisalexandercook

Thanks for the PR! I'm wondering if it is worth it to also handle the CRLF vs. LF mismatch in a .gitattributes file, would it eliminate the need to use this command? Some information on this here:

https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings#re-normalizing-a-repository

YutongZhuu · 2025-09-20T01:05:53Z

Thanks for the PR! I'm wondering if it is worth it to also handle the CRLF vs. LF mismatch in a .gitattributes file, would it eliminate the need to use this command? Some information on this here:

https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings#re-normalizing-a-repository

Hi, I think that is a better idea. I added the .gitattributes file, I hope I didn't forget to mark any binaries in that file. And I also followed the steps in the link you sent to refresh the project.

thisisalexandercook

Thanks for adding the attributes file, a few comments...

thisisalexandercook · 2025-09-23T16:47:35Z

+*.class   binary
+*.png     binary
+*.jpg     binary
+*.pdf     binary


Two things:

(1) We have all of these binary files in our repo except .jpg. Wondering if we should only include file extensions we currently use or future proof it?

(2) I think the red circle with a - at the bottom of this diff means you don't have a newline char at the end of this file.

(1) That was my intention, I must've forgot to delete it from the template.
(2) Will fix that

thisisalexandercook · 2025-09-23T16:49:24Z

-Ensure line endings are handled properly. If necessary, run
-\code{git config --global core.autocrlf true} to prevent line ending issues between
-Windows and Unix-based systems.
-


I think it probably makes sense to leave some comment in the manual about this. Maybe mention its automated through .gitattributes and discuss its equivalence to using this command

Added descriptions about that.

thisisalexandercook · 2025-09-23T16:50:05Z

-:mainEnd
-if "%OS%"=="Windows_NT" endlocal
-
-:omega


Do we have a diff here because of the .gitattributes change?

Yes, I think that is caused by git add --renormalize .

ah I see, thanks for clarifying. I’m wondering if we actually don't want this file normalized to LF in the repo, since it’s a Windows-only batch file.

Here’s how I understand * text=auto: when we stage/commit a file, Git normalizes its contents to LF before writing the blob to the object database. This is great for cross-platform consistency because history is always LF-based, but on Windows a user with core.autocrlf=true will still check the file out with CRLF locally, so editing it works fine.

Does this seem correct? And would we rather force CRLF in the repo for this one file so that even users without core.autocrlf get a windows-esque formatted batch file? I guess our goal here is to remove the need for users to have specific format settings, but still allow flexibility if they are set.

I updated the .gitattributes to force bat files to have CRLF endings. However, I am not able to revert this change by applying git add --renormalize . again because the file is already stored as a CRLF file.

❯ file gradlew.bat gradlew.bat: DOS batch file text, ASCII text, with CRLF line terminators

So it seems the file is already in the correct CRLF format — please let me know if that aligns with what we wanted for Windows batch files.

I had to drop the commit to revert the change I made to gradlew.bat, and my local git now always think that gradlew.bat is modified after I dropped the commit. I am not sure why.

thisisalexandercook · 2025-09-29T17:25:48Z

-:mainEnd
-if "%OS%"=="Windows_NT" endlocal
-
-:omega


ah I see, thanks for clarifying. I’m wondering if we actually don't want this file normalized to LF in the repo, since it’s a Windows-only batch file.

Here’s how I understand * text=auto: when we stage/commit a file, Git normalizes its contents to LF before writing the blob to the object database. This is great for cross-platform consistency because history is always LF-based, but on Windows a user with core.autocrlf=true will still check the file out with CRLF locally, so editing it works fine.

Does this seem correct? And would we rather force CRLF in the repo for this one file so that even users without core.autocrlf get a windows-esque formatted batch file? I guess our goal here is to remove the need for users to have specific format settings, but still allow flexibility if they are set.

thisisalexandercook · 2025-09-29T17:27:22Z

@@ -0,0 +1,9 @@
+# Set the default behavior, in case people don't have core.autocrlf set.
+* text=auto
+


Suggested change

gradlew.bat text eol=crlf

Can test to see if this works if omitting this file seems correct

thisisalexandercook · 2025-10-06T17:13:13Z

+*.jpg     binary
+*.pdf     binary
+
+*.bat text eol=crlf


Ive tested this in action and it appears to be working correctly. To test you can do the following:

run git add --renormalize .
This will remove ^M from .bat file

run git commit -m format: normalized .bat files for repo

switch to some other branch then switch back to the one for this PR with the .gitattributes updates

run git show HEAD:gradlew.bat | cat -v
Checks the line endings of the commited .bat file, should see no ^M endings

run cat -v gradlew.bat
Shows line ending of the working tree version of gradlew.bat, should see ^M

So maybe we want .bat files commited to the repo with LF endings?Then the entire repo is LF normalized and the .gitattributes file handles working tree conversions depending on the local machine.

I thought your original suggestion was to ignore .bat files because it was window-only. But yes, I don't see anything wrong with using LF normalization in the entire repo.

Yes, I think my understanding of how the .gitattributes file worked was inverted RE: our conversation this morning. Its not that it converts a git blob to CRLF on commit, it does it on checkout and to the worktree only. So with this, your original push that convert the .bat to LF in the repo makes sense.

I see, I applied the normalization again.

wmdietl · 2025-12-22T03:38:28Z

CI is repeatedly failing with:

> Task :javacutil:classes UP-TO-DATE
> Task :javacutil:jar
> Task :framework:copyAndMinimizeAnnotatedJdkFiles
Exception in thread "main" java.lang.StackOverflowError
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)

It seems a bit odd that this is related to this PR, but other PRs are passing.
I assume the build works for you locally?

As there is also some issue with changes to gradlew.bat, can you start from a fresh branch and apply just your desired changes?

Thanks again for the contribution!

YutongZhuu · 2025-12-27T18:04:30Z

CI is repeatedly failing with:

> Task :javacutil:classes UP-TO-DATE
> Task :javacutil:jar
> Task :framework:copyAndMinimizeAnnotatedJdkFiles
Exception in thread "main" java.lang.StackOverflowError
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)

It seems a bit odd that this is related to this PR, but other PRs are passing. I assume the build works for you locally?

As there is also some issue with changes to gradlew.bat, can you start from a fresh branch and apply just your desired changes?

Thanks again for the contribution!

Hi, sorry for the delay.

Yes, the build works for me locally.

The changes to gradlew.bat was intended, so it was my desired change. From the discussion with @thisisalexandercook, normalizing the line endings of gradlew.bat was a good idea.

I am not sure why the changes in this PR would cause the accept function to be called recursively without a termination. Does the copyAndMinimizeAnnotatedJdkFiles try to parse the gradlew.bat file?

wmdietl · 2025-12-31T20:15:00Z

Thanks for the update @YutongZhuu !
CI is still failing with a StackOverflowError, only in this PR. Can you try to fix the CI issue, e.g. by breaking down the changes into smaller changes, starting from a fresh branch?

YutongZhuu · 2026-01-01T06:25:06Z

Thanks for the update @YutongZhuu ! CI is still failing with a StackOverflowError, only in this PR. Can you try to fix the CI issue, e.g. by breaking down the changes into smaller changes, starting from a fresh branch?

Sure, I will do that.

YutongZhuu · 2026-01-15T22:28:59Z

@wmdietl Hi, could you give me the permission to run the workflow? I will apply commits one by one to see which one breaks the CI. Sorry for the delay.

wmdietl · 2026-01-15T22:33:56Z

@wmdietl Hi, could you give me the permission to run the workflow? I will apply commits one by one to see which one breaks the CI. Sorry for the delay.

I don't see a simple way to give you just that permission. If there is some other PR you want to make, open that. Once you have a merged PR, CI should automatically run for you.

YutongZhuu · 2026-01-15T23:04:57Z

@wmdietl Hi, could you give me the permission to run the workflow? I will apply commits one by one to see which one breaks the CI. Sorry for the delay.

I don't see a simple way to give you just that permission. If there is some other PR you want to make, open that. Once you have a merged PR, CI should automatically run for you.

I am not sure what you meant, I have to merge a PR to run the CI?

thisisalexandercook · 2026-01-16T00:39:48Z

@YutongZhuu you can also make CI run in your own fork by opening a PR and turning on GitHub actions.

YutongZhuu · 2026-01-16T01:25:01Z

@YutongZhuu you can also make CI run in your own fork by opening a PR and turning on GitHub actions.

Oh, I didn't know that. Thank you for letting me know!

thisisalexandercook

Thanks for reopening this! It is curious that CI passed when run again. My only comment is that it is best practice not to submit a PR using your forks master branch.

YutongZhuu · 2026-02-08T03:49:51Z

Thanks for reopening this! It is curious that CI passed when run again. My only comment is that it is best practice not to submit a PR using your forks master branch.

Thanks for the note! I will not do that again in the future.

wmdietl · 2026-02-10T02:01:55Z

CI is failing with the stack overflow again:

> Task :framework:copyAndMinimizeAnnotatedJdkFiles
Exception in thread "main" java.lang.StackOverflowError
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)

wmdietl · 2026-02-22T18:05:30Z

Some targets, mostly misc, still fail with:

> Task :framework:copyAndMinimizeAnnotatedJdkFiles
Exception in thread "main" java.lang.StackOverflowError
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)

Other targets, e.g. the junit and nonjunit targets, pass, even though they also execute copyAndMinimizeAnnotatedJdkFiles.

We need to figure out why adding the gitattributes file has this effect.

YutongZhuu · 2026-02-22T21:02:29Z

Some targets, mostly misc, still fail with:

> Task :framework:copyAndMinimizeAnnotatedJdkFiles
Exception in thread "main" java.lang.StackOverflowError
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)
	at com.github.javaparser.ast.validator.TreeVisitorValidator.accept(TreeVisitorValidator.java:40)

Other targets, e.g. the junit and nonjunit targets, pass, even though they also execute copyAndMinimizeAnnotatedJdkFiles.

We need to figure out why adding the gitattributes file has this effect.

I think the problem comes from the changes in ‎gradlew.bat. I normalized the line endings in that file. I will revert that change to see whether the CI passes or not. Maybe we should open another PR for the gradlew.bit changes since the initial intention of this PR was only adding a gitattribute file. Let's not worry about that here.

wmdietl · 2026-02-24T17:40:09Z

@YutongZhuu CI is still failing with the same exception. It would have been weird if the reformatting of gradlew.bat would cause an issue on systems that don't use .bat files.

However, I don't have an idea why adding .gitattributes would cause this CI failure.

YutongZhuu · 2026-02-24T17:45:09Z

@YutongZhuu CI is still failing with the same exception. It would have been weird if the reformatting of gradlew.bat would cause an issue on systems that don't use .bat files.

However, I don't have an idea why adding .gitattributes would cause this CI failure.

On think the CI passes on this commit:

Maybe there are some conflicts (I don't mean git conflicts) with the master branch since it fails after you merged the master into this branch? I am not sure.

wmdietl · 2026-02-24T17:54:08Z

This is really weird since I and @thisisalexandercook had seen it passing in the other PR I opened. Maybe there is something wrong with the PR itself?

Sure, try opening a new PR again. If it contains the same changes, it hopefully is at least reproducible.

I've also asked Copilot, let's see whether it suggests anything actionable in #1548.

wmdietl · 2026-02-24T18:28:20Z

I'm trying the change suggested in #1548, but it seems very unlikely to me that that would fix this issue - the deep nesting of JDK files would exist in all PRs.

thisisalexandercook · 2026-02-24T20:40:43Z

@wmdietl maybe something interesting...

In the failing runs, the logs show CI_ORGANIZATION=wmdietl. In other PRs, CI_ORGANIZATION is the PR owner instead, but since you are enabling CI here it is set to you (this is set by an internal github var called GITHUB_ACTOR that our scripts use). This matters because checker/bin-devel/clone-related.sh calls git-clone-related eisop jdk, and the helper scripts use CI_ORGANIZATION to prefer ${CI_ORGANIZATION}/jdk if it exists, and falls back to eisop/jdk if not. This fork-selection logic is in eisop-plume-lib/git-scripts, specifically git-find-fork.

So here, since wmdietl/jdk exists, it clones that. The only problem is that this repo is not an annotated-jdk fork, its just a fork of openjdk/jdk that is about 26k commits behind, and ends up being used as input for copyAndMinimizeAnnotatedJdkFiles.

But why doesn’t this happen every time @wmdietl runs/re-runs CI on a PR? Because git-clone-related doesn’t only use CI_ORGANIZATION it also uses CI_BRANCH_NAME (the PR head branch). When it tries ${CI_ORGANIZATION}/jdk, that repo must also have a branch matching CI_BRANCH_NAME, if not it falls back to eisop/jdk. And in this particular PR, @YutongZhuu has pushed against his forks master branch, and master does exist in wmdietl/jdk. The perfect storm.

wmdietl · 2026-02-24T21:21:02Z

But why doesn’t this happen every time @wmdietl runs/re-runs CI on a PR? Because git-clone-related doesn’t only use CI_ORGANIZATION it also uses CI_BRANCH_NAME (the PR head branch). When it tries ${CI_ORGANIZATION}/jdk, that repo must also have a branch matching CI_BRANCH_NAME, if not it falls back to eisop/jdk. And in this particular PR, @YutongZhuu has pushed against his forks master branch, and master does exist in wmdietl/jdk. The perfect storm.

Thanks for tracking this down, @thisisalexandercook !

In the misc task, as you explain, I do see:

git-clone-related: About to run: git clone -q -b master -q --single-branch --depth 1 https://github.com/wmdietl/jdk.git ../jdk
git-clone-related: ../jdk is at c8b6cfbdc53dd0b58f05f234bfa46c9d4b709e88

With the much larger stack size, the task now fails with:

* What went wrong:
Execution failed for task ':framework:jar'.
> Archive contains more than 65535 entries.

However, in the other tasks, I see:

git-clone-related: About to run: git clone -q -b master -q --single-branch --depth 1 https://github.com/eisop/jdk.git ../jdk
git-clone-related: ../jdk is at 9d40ad20e43217893af1fa818edbe45ec8d11f4e

Could you file issues for:

Improve the developer manual: document the general recommendation to make PRs from a branch?
Figure out why this problem only exists for misc? We should clone the same JDK in all checks, to get consistent behavior.
Why is it failing with that old fork of openjdk/jdk? There simply shouldn't be any annotated files here

checker-framework/framework/build.gradle

Line 129 in 713edcd

if (line.contains('@AnnotatedFor') || line.contains('org.checkerframework') || line.contains('org.jspecify')) {

. The failure with a stack overflow and the one with 65535 entries seem odd.

@YutongZhuu Please make a PR from a branch. It was great to figure out this issue with our CI system. Let's try to document it better and avoid running into this issue in the future.

Thanks!

YutongZhuu · 2026-02-24T22:12:40Z

But why doesn’t this happen every time @wmdietl runs/re-runs CI on a PR? Because git-clone-related doesn’t only use CI_ORGANIZATION it also uses CI_BRANCH_NAME (the PR head branch). When it tries ${CI_ORGANIZATION}/jdk, that repo must also have a branch matching CI_BRANCH_NAME, if not it falls back to eisop/jdk. And in this particular PR, @YutongZhuu has pushed against his forks master branch, and master does exist in wmdietl/jdk. The perfect storm.

Thanks for tracking this down, @thisisalexandercook !

In the misc task, as you explain, I do see:
git-clone-related: About to run: git clone -q -b master -q --single-branch --depth 1 https://github.com/wmdietl/jdk.git ../jdk
git-clone-related: ../jdk is at c8b6cfbdc53dd0b58f05f234bfa46c9d4b709e88
With the much larger stack size, the task now fails with:
* What went wrong:
Execution failed for task ':framework:jar'.
> Archive contains more than 65535 entries.
However, in the other tasks, I see:
git-clone-related: About to run: git clone -q -b master -q --single-branch --depth 1 https://github.com/eisop/jdk.git ../jdk
git-clone-related: ../jdk is at 9d40ad20e43217893af1fa818edbe45ec8d11f4e
Could you file issues for:

Improve the developer manual: document the general recommendation to make PRs from a branch?

Figure out why this problem only exists for misc? We should clone the same JDK in all checks, to get consistent behavior.

Why is it failing with that old fork of openjdk/jdk? There simply shouldn't be any annotated files here

checker-framework/framework/build.gradle

Line 129 in 713edcd

if (line.contains('@AnnotatedFor') || line.contains('org.checkerframework') || line.contains('org.jspecify')) {

. The failure with a stack overflow and the one with 65535 entries seem odd.

@YutongZhuu Please make a PR from a branch. It was great to figure out this issue with our CI system. Let's try to document it better and avoid running into this issue in the future.

Thanks!

Opened, #1549.

thisisalexandercook self-assigned this Sep 16, 2025

thisisalexandercook reviewed Sep 16, 2025

View reviewed changes

YutongZhuu changed the title ~~Update troubleshooting.tex~~ Add .gitattribute Sep 20, 2025

YutongZhuu changed the title ~~Add .gitattribute~~ Add .gitattributes file Sep 20, 2025

YutongZhuu requested a review from thisisalexandercook September 21, 2025 19:31

thisisalexandercook reviewed Sep 23, 2025

View reviewed changes

thisisalexandercook assigned YutongZhuu and unassigned thisisalexandercook Sep 23, 2025

YutongZhuu requested a review from thisisalexandercook September 24, 2025 18:08

thisisalexandercook reviewed Sep 29, 2025

View reviewed changes

YutongZhuu force-pushed the master branch 2 times, most recently from 90e3071 to d437d8b Compare October 5, 2025 21:54

YutongZhuu requested a review from thisisalexandercook October 5, 2025 22:04

thisisalexandercook reviewed Oct 6, 2025

View reviewed changes

YutongZhuu requested a review from thisisalexandercook October 6, 2025 23:10

YutongZhuu closed this Jan 15, 2026

YutongZhuu force-pushed the master branch from c509459 to 45330fc Compare January 15, 2026 22:16

YutongZhuu reopened this Jan 15, 2026

YutongZhuu closed this Jan 26, 2026

YutongZhuu force-pushed the master branch from 82d0538 to 71e52cd Compare January 26, 2026 03:53

YutongZhuu added 7 commits January 29, 2026 21:12

Update contributors.tex

596404d

Edit troubleshooting.tex

f4e706f

Add .gitattributes

1078e5c

Remove paragraph about core.autocrlf from tex file

657a446

Add newline in .gitattributes

cbc6e78

Add info about .gitattributes in the doc

0375148

Update .gitattributes

84111c0

YutongZhuu reopened this Feb 6, 2026

thisisalexandercook approved these changes Feb 7, 2026

View reviewed changes

YutongZhuu force-pushed the master branch from a9a6af0 to 84111c0 Compare February 22, 2026 21:03

Merge branch 'master' into master

7f9f402

Copilot AI mentioned this pull request Feb 24, 2026

Fix StackOverflowError in copyAndMinimizeAnnotatedJdkFiles task #1548

Closed

Add JVM stack size argument

939b7b1

YutongZhuu mentioned this pull request Feb 24, 2026

Add .gitattribute file #1549

Merged

wmdietl mentioned this pull request Feb 25, 2026

Document learnings from CI issues in a PR #1553

Open

wmdietl closed this Feb 25, 2026

		@@ -0,0 +1,9 @@
		# Set the default behavior, in case people don't have core.autocrlf set.
		* text=auto

Conversation

YutongZhuu commented Sep 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thisisalexandercook left a comment

Choose a reason for hiding this comment

Uh oh!

YutongZhuu commented Sep 20, 2025

Uh oh!

thisisalexandercook left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

wmdietl commented Dec 22, 2025

Uh oh!

YutongZhuu commented Dec 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wmdietl commented Dec 31, 2025

Uh oh!

YutongZhuu commented Jan 1, 2026

Uh oh!

YutongZhuu commented Jan 15, 2026

Uh oh!

wmdietl commented Jan 15, 2026

Uh oh!

YutongZhuu commented Jan 15, 2026

Uh oh!

thisisalexandercook commented Jan 16, 2026

Uh oh!

YutongZhuu commented Jan 16, 2026

Uh oh!

thisisalexandercook left a comment

Choose a reason for hiding this comment

Uh oh!

YutongZhuu commented Feb 8, 2026

Uh oh!

wmdietl commented Feb 10, 2026

Uh oh!

wmdietl commented Feb 22, 2026

Uh oh!

YutongZhuu commented Feb 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wmdietl commented Feb 24, 2026

Uh oh!

YutongZhuu commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wmdietl commented Feb 24, 2026

Uh oh!

YutongZhuu commented Sep 14, 2025 •

edited

Loading

YutongZhuu commented Dec 27, 2025 •

edited

Loading

YutongZhuu commented Feb 22, 2026 •

edited

Loading

YutongZhuu commented Feb 24, 2026 •

edited

Loading

thisisalexandercook commented Feb 24, 2026 •

edited

Loading