A 185-file uploader covers batches, accounts, and duplicate checks
At commit 642c900, gotohp occupied 4 MB across 185 files and about 22,950 lines of source. Its job is narrower than a photo manager: send individual files or directories to Google Photos, optionally scan subdirectories, choose an account, and skip media already present. The graphical app adds drag and drop, live progress, saved preferences, and configurable workers. A separate CLI exposes the same upload engine for scheduled jobs and shell scripts.
Operators can select recursive scanning, upload threads, another config file, or a stored account by email. In v0.11.0, proxy, quality, quota, and other upload behavior come from flags rather than GUI preferences. That keeps desktop preference changes out of scripted runs. Credential storage remains shared, so protect the config and any token file passed through standard input.
Three sign-in routes all expose unusual Google credentials
The easiest documented route opens Google Embedded Setup, asks the user to sign in, and then requires browser developer tools to copy the oauth_token cookie. The page may keep loading forever, which the README says is expected. Another route uses Google Photos ReVanced with GmsCore and reads an Android authentication line through ADB. The third route needs a rooted device or emulator, HTTP Toolkit interception, and sometimes an Android AccountManager binding key.
All 3 routes create an adoption boundary. gotohp calls itself unofficial, and the user hands it a credential obtained outside a normal desktop OAuth redirect. A company with managed Google accounts may reject that process. Personal users should keep the cookie out of shell history, screenshots, and bug reports, then restrict the shared config file.
What happened when we ran it
Our sandbox installed 196 packages in 43 seconds using an unprivileged Debian container with 3 CPUs and 8 GB of RAM. The source checkout was 4 MB, and dependency installation completed without an error. The build then succeeded in 6 seconds. This establishes that commit 642c900 could compile through the build step in our stated Go 1.24 environment; it does not test a Google login or an actual photo upload.
The test command failed with exit code 1 after 45 seconds, with go test recording 0 passed and 7 failed of 7. Its final output says pkg-config could not find libsoup-3.0 or gio-unix-2.0. The app reported setup failure, while the backend and internal CLI packages reported build failures. The log does not identify any test assertion or application defect beyond those unavailable libraries, so we cannot turn the result into a claim about upload correctness.
Our scan found 3 CI workflow files, no Dockerfile, and no tests directory among 185 files. Go can keep tests beside source, so the missing folder alone says little. Fresh Debian lacked the native Linux dependencies needed for every tested package. The README only links to the Wails3 guide and does not name the two packages in our log.
Version 0.11.0 makes CLI jobs independent of GUI preferences
Release v0.11.0 was published on September 14, 2026. It changes the config into account and preference sections, migrates old flat files on first load, and stops the CLI from inheriting upload behavior from the GUI. Existing automation must now pass flags such as proxy, saver, quota, and account explicitly. The release also fixes unsuccessful uploads so the CLI returns a failure exit code, an important property for cron jobs and scripts that decide whether to alert or retry.
Release assets include GUI packages and CLI binaries for Windows, macOS, and Linux, plus checksums. Our 6-second build says nothing about those artifacts on a particular desktop, but users can avoid assembling Wails3 locally. With no Dockerfile, headless operators must package the CLI themselves.
Nine open issues and PRs show an uploader that is still filling gaps
GitHub showed 576 stars and 9 combined issues and pull requests, with both a push and v0.11.0 release on September 14, 2026. The active queue is small enough to inspect rather than summarize as a bug count. One pending pull request prepares v0.11.1. Issue 71 asks to archive uploads or add them to an album, while issue 22 asks for downloading by media key. These are useful boundaries around what the current uploader does.
Batch recovery is the sharper concern after our 45-second failed test run. Issue 58 asks for pause and resume because closing the app can trigger rate limiting during duplicate checks after restart. Issue 26 requests resumable folder uploads and a file containing failures after a large library froze partway through. Issue 61 proposes a local database for rename and deletion sync in both directions. None of those requests is proof that every large job fails, but all describe functions a dependable sync client would need.
A 4 MB uploader should complement a photo archive, not become one
gotohp fits a focused migration or recurring upload job where Google Photos remains the destination. Its 185-file codebase, GUI, and CLI are easier to understand than a replacement photo platform. The project can avoid resending media it finds in the account, but open download and two-way sync requests mean it should not hold the only record of what exists. Keep original files and an independent backup until counts and spot checks confirm the upload.
Immich is the better comparison when you want to operate the whole photo library yourself. rclone suits broader command-line transfers, subject to the Google Photos backend's API limits, while archived gphotos-sync is aimed at pulling a Photos library down. gotohp wins the narrow trial when upload convenience outweighs the 43-second dependency setup, unusual sign-in, and missing pause support. For unattended work, test failure exits, interrupted batches, duplicate handling, and credential recovery before trusting the schedule.