Is this file intended to be checked in? The test commands seem specific to this change. If not, maybe gitignore it?

I'll remove it before landing.

I keep it in the git history because I often find myself referring to these files in old PRs after I haven't touched the repo in a while and need to remember how to do things. I find it is a good historical reference of what commands I was actually running at the time.

I also get a lot of value while working on a PR from seeing the diffs of this file over time.

Ideas on better ways to organize these somewhat personalized tooling files?

Also, I can ask questions like this: @isaacbrodsky, is this how you typically run tests in the repo? Do you tend to run ctest directly or commands like make test-fast? Do you know of a way to run just the CLI tests, or just one CLI test? Currently, ctest runs both the C and CLI tests.

:)

I usually run make test or make test-fast. When debugging in more detail I would switch to ctest since that provides more direct control and feedback about verbosity, print-on-error, etc. When debugging a specific failure I would then go to running the test binary directly, since I may need to run it under valgrind or lldb/gdb or something.

For the CLI tests I think I mainly run them through make test. For running a specific CLI test I would probably copy out the command from the applicable CMake file.

I don't have a recommendation on the specific commands ran. I feel this would be personal unless you document more about what the commands are and why someone would want to run them. For that I would either gitignore or keep in another branch or repo (as with dotfile repos). Unfortunately that loses the association with which uber/h3 commit they go. You could then try to use submodules to take care of that but my experience is most people find submodules challenging to work with.

Thanks. For the justfile, I'll probably just stick to my plan of keeping it in the git history while developing, removing it before merging, and then squash merge at the end to keep the history clean.

Could add it to .gitignore and then keep it in your local?

I like to keep it in the git history to see how it changes as I work on the diff, and also to be able to reference it later when I come back in a few months and I forget how to build everything. Removing at the last commit and then squashing (to remove it from the repo history) seems like a good compromise, but always open to other ideas!

I see how I made this mistake. In most of the code the error condition is the "truthy" value, but here success is true, though I named these variables as if they were H3Errors. That feels like a point against Hungarian Notation.

@ajfriend should lines 265-268, 285-288, 391-394, and 420-423 be updated as well?

Yeah, fixed in #1055

Ah, good catch @LucaDiba! And thanks for the fix @justinhwang!